Tag Info

New answers tagged

0

This work correctly for me (the comments indicate what we are generating line-by-line): <img src="x" onerror="([] [( // []. ({}+[]) [!+[]+!+[]+!+[]+!+[]+!+[]] + // 'c' ({}+[]) [+!+[]] + // 'o' ([]['']+[]) [+!+[]] + // 'n' ([![]]+[]) [!+[]+!+[]+!+[]] + // 's' ([!![]]+[]) [+[]] ...


2

An obvious scenario, as @schroeder pointed out in one of the comments, is when the server inspects strings for blacklisted strings like alert(1). Apart from that, in order for the payload to work, the application must meet the following conditions: There should be no restriction on the input length (as you can see, the payload can be enormous length). The ...


0

The best solution would be to blacklist certain characters and sequences (recursively). It all depends on how much usability you are willing to sacrifice for security. You can blacklist scripts tags and somebody can use img src=# onerror etc. It can't hurt to do that if these sequences aren't ever expected but again I don't know the use of your ...


0

From the UI snippet alone, we cannot tell much, but given your pseudo-code of: http:// + {Whatever host they typed} + : {Whatever port they typed} + /path/ You might be in danger of someone crafting the following input: http:// + {evil.com/evil_script.php?http://10.16.1.159} + : {8080} + /path/ In this case, the evil script now can input to your website ...


0

Answer Updated : You need the eval to convert you coded javascript to string because otherwise the browser could not take it in consideration as an instruction. When you look at the code used on http://www.jsfuck.com/ the "run function" use eval no matter what $("run").onclick = function(){ value = eval($("output").value); if (!$("eval").checked){ ...


2

The HttpOnly flag only serves to protect sensitive cookies from scripts. Assuming the load balancing cookie is only concerned with routing through to a specific server and cannot identify a client, there's no harm in this cookie being exposed. A XSS attack will only identify which server the browser is connecting to, and not anything specific to the client ...


1

XSS only happens when data is output. In your code sample you are setting the variable myhash to the hash value in the address bar. As your code doesn't contain any sinks and your variable is not output, the above code, in isolation, is not vulnerable. However, to check for XSS vulnerabilities you need to focus on output to your application rather than ...


1

Perhaps the the XSS-code ended up inside a tag of which the contents are interpreted as text-only, such as <title> or <textarea>. Try prepending the XSS code with </textarea> or </title> if this is the case. It may also have ended up in an attribute of an element, in which case you need to close the attribute and element using "> ...


2

Your source content <a href="/search?text="><script>alert('Found')</script> seems to show that your application is vulnerable to XSS. I think your browser is just mitigating the injection because it detects that it's inline javascript. Maybe you are using a framework that is sending to your browser some mitigation headers. Look at the ...


5

Some scanners simply search for the injected string ("found" in this case) somewhere on the page, if "found" is in the search results, then it would classify it as a positive finding. If the XSS string is being interpreted as a string in the search function (literally searching for the string <script>alert('Found')</script>, then you can chalk ...


-1

Are you doing it in Chrome? Chrome has an XSS auditor which can block a lot of XSS attacks. If you are in Chrome, you can open the Developer Tools window and it will show when XSS attacks are blocked. You may also want to try a different browser like IE.


3

This works for me: <html> <img src=1 ...


0

Yes, they could poison cookies on your domain to execute say a Session Fixation attack. e.g. The attacker visits your main website www.example.com and gets a session ID. The attacker adds some JavaScript to their page at attacker.example.com to set the session cookie at .example.com to be the same as the session ID. They entice their victim to visit ...


1

There are several browser-side mechanisms, that work domain-wide and thus can be affected by this idea, at least: Firefox NoScript plugin - permissions to run individual scripts are domain-wide, so enabling scripts for one user will result in enabling scripts for all users cookie visibility Flash access permissions Java access permissions JavaScript access ...


1

A CSRF attack can only happen when cookies (or other authentication mechanisms) are provided by the client automatically. That is, where the client has access to cookies from multiple domains (such as a web browser storing cookies for each site you visit). However, a mobile app containing a web viewer will typically only have the cookies for its own system. ...


2

What should I do to mitigate the damage? Usually, it is the user's browser that is compromised by XSS vulnerabilities on web sites. You probably won't see any damage done to your site, especially since it was reflected XSS. The attacker would need to target each user separately and convince them to click a malicous link in an email or visit a malicious ...


4

The first step is to patch the vulnerability by escaping any HTML entities or removing any dangerous characters all together. Reflected XSS is a client-side attack method, caused by a server side vulnerability. I wouldn't worry too much about any damages if you didn't catch an XSS worm in action or actually saw anyone using the exploit to attack other ...


4

I haven't studied this specific vulnerability, but from the points you mention I should note: Cross-Frame-Options is not used too much on websites. Although this SOP vulnerability is dwarfed by X-Frame-Options, two months before there was another one where it didn't seem to matter. Most outdated phones where you will be able to exploit one of them, most ...


1

XSS is usually an attack against a server. Unless your phone is serving Web pages to external connections this should not be a problem. If your server that is serving the pages to the phone is vulnerable then XSS is identical to a normal website - with the exception it may be harder to trick someone into following a link. Unless your application takes in ...


3

This could conceivably be abused for HTML injection. Imagine if a user searched for the term waterfall</a><a href="http://maliciouslink.com">Click Here The </a> in the search term would terminate the mailto link, and then insert a second link with the words "Click Here". URL encoding will of course mitigate this problem. Also, make ...


2

You need to URL-encode SEARCHED_QUERY_HERE, otherwise if a user searches for &body=something, the body of the e-mail message will be set to something. Also, if you don't URL-encode it, if the user searches for a literal %20 (or similar) it will appear as a space in the message instead. This is not a security risk, though. The other, obvious risk is ...


0

I don't think so, but the greater concern is that you're allowing user input to modify the returned page. Make sure you're using a good API for validating user input (as it is used to generate the query) and that you are properly protecting the output in this page. Use OWASP's ESAPI if possible.



Top 50 recent answers are included