New answers tagged xss
-1
Looks like the simple solution (i.e., CSRF protection but with all-cacheable web resources) is to just add a separate cookie containing the anti-CSRF token but accessible to page javascript.
In other words, when the client logs in, I'll actually set two cookies (one HttpOnly sessionid and one non-HttpOnly anti-CSRF token, accessed by page scripts). So, the ...
2
To exploit this flaw, the attacker would need to manipulate the user’s cookie. And this is only possible if he is able to exploit another vulnerability that allows him to set the cookie with the XSS payload as one can only set cookies within the domain the Set-Cookie originated from:
The user agent will reject cookies unless the Domain attribute
...
0
The only real attack vector would exist in a situation where there is another vulnerability. For example if you could upload an executable script such as some PHP code you could manipulate the cookie using that script to inject some JavaScript into the users session. You would also need to perform the usual social engineering to get the user to visit your ...
1
Once upon a time flash was vulnerable to CRLF injection, and this could have been used to set the Cookie: HTTP request header to exploit cookie-based XSS. But this is no longer the case. It is not possible to set a Cookie on another domain. If you could set cookies for other domains it would make session fixation very difficult to prevent (if not ...
1
It's useless. Due to the same-origin policy, text on a page cannot be read by other sites, just like cookies.
It is readable by an attacker running an MITM attack, but so are the cookies (unless the connection is HTTPS).
1
The problem with this implantation is that the CSRF token is not actually stored within an anonymous function. This token would be stored within text that declares an anonymous function. An XSS payload can request this text from the server using an XHR, the CSRF token can be read and another XHR can be used to send an arbitrary forged request.
Related: ...
2
The only time that you need to worry about the token being read is if there's a malicious extension or an MITM attack being carried out.
In both cases, it's no longer a CSRF problem. Both attacks have the capability of catching the request on the fly (after your javascript has assembled it with the token) and modifying it. This isn't CSRF, but it's still a ...
0
As mentioned by a number people - double submit is an ok CSRF protection, provided that you use a separate nonce. Using session id is very wrong in this context, starting with the fact that sessionid has to be HTTPOnly for XSS protection.
An argument of "what if there is XSS on this page/website" is not valid - when you have XSS, CSRF is the least of your ...
1
You could, but it seems a bit unwieldy to me. Any CSRF-prevention mechanism works like this:
Make the server only accept requests that satisfy some conditions
Ensure that the conditions are something that can't be forged
Write your HTML so that the requests it generates follow the conditions set by the server.
The tried-and-tested method is to use ...
13
Quoted from OWASP's CSRF Prevention page:
Double Submit Cookies
Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value ...
9
No because you should never allow scripts to be able to access your cookies. Refer to HTTPOnly on the OWASP website.
To prevent people from being able to steal session id's, should XSS be present, you should always set this cookie flag. Your mechanism would not work anymore as it would not be able to access the cookie.
1
XSS occurs when a piece of browser scripts origin from 3rd-party sources be injected into a vulnerable website's content, which can be considered as instructions to the user's browser to "present" a website. In web's terminology, the user's browser believes that such instructions are legitimate within the web site domain. In XSS scenario, the returned ...
4
Because of the same-origin policy, in the XSS case, the script needs to be loaded in the user's browser in a page on the same domain you're trying to attack.
So, to steal an example.com cookie from a user, you need to "inject" that JavaScript in a page on example.com. For example, example.com/viewArticle.php?id=4123&comments=1 where the comment section ...
3
Let's illustrate how a basic page request works:
Request
index.php
#4 Processing |--------| 1#-----------> |--------| #2 Processing
HTML/CSS/JS | Client | | Server | the requet
etc... |--------| <-----------#3 |--------|
Sending
...
3
The server does not parse JavaScript except under very specific circumstances (i.e. you run NodeJS and you eval() a user input. Someone would have to be bloody stupid to do that or have a very valid reason to do so). So, the server does not see/care about the actual content of the code, and it won't be executed server-side. The reason for something like ...
2
A problem could be that if you assume that the input is in a different encoding than the browser. (If you don't tell the browser what encoding he should use, most browsers try to guess it).
This problem for example has hit Google's 404 page.
Here was the fact exploited that IE guesses the encoding of a page as UTF-7 if it finds a valid UTF-7 sequence in the ...
1
AngularJS Batarang seems to be the tool you might be looking for. It's a Chrome Developer Tools extension that adds support for debugging and profiling AngularJS applications.
Other than that, you could also inspect values the standard way by accessing DOM element values by JavaScript. It might be a bit tricky to get a pointer to the exact element in ...
0
Dominator pro is excellent when it come to xss. I had used it and found xss on multiple site like apple,yahoo,google,wizehive and in payment gateway of accessnow.org and flipkart etc. The bad thing about tool is, it is freezing time which is most important.
10
It depends on the context the injection happens.
Obviously, if the injection happens in the context of an elements content like this one:
<p>Your search for "❌" has returned the following results:</p>
< is required to switch from text to markup. But even here, if you echo user input in a <script>, e.g.:
<script>var search = ...
6
Short answer: No.
Long answer: In a lot of cases, yes, but don't do it.
Someone correct me if I'm wrong about anything here.
If, and only if, the text is only outputted to "the body" of a standard styling element, and if that body isn't then grabbed by some Javascript or otherwise, then I would honestly have to say yes. By body I mean the text is being ...
1
Nope because there are ways which actually omit the < > tags. Input should be treated as a string so you need to properly encode it. I suggest you have a look at the owasp testing guide v3
1
In its current state, your code doesn't have a DOM XSS vunerability. $.val sets the value of a form element, which cannot be used to inject JavaScript code into a website.
The innerHTML property or document.write are examples for methods that are vulnerable to DOM based XSS.
You should read up on this topic on the OWASP website. There's also a talk here ...
Top 50 recent answers are included
