Tag Info

Hot answers tagged

13

JavaScript, the Definitive Guide, 4th Edition - published in 2001 - mentions these in a bit more detail. The relevant section appears to be freely available. It's right at the bottom of that link. Here's the excerpt: 12.2.5. JavaScript in Nonstandard Contexts Both Netscape and Microsoft have implemented proprietary extensions in their browsers, and ...


4

Reflected XSS I send a victim a link to http://example.com/page?var=<script>alert('xss')</script> and somewhere on the page that value is echoed back to the victim. The value is only on the page if they follow my special link. The downside of this type is I have to specifically attack one victim or a group of victims who I can get to click on a ...


3

Fundamentally XSS is one of: Failure of input validation Failure of output escaping If you have well known data entry points you can potentially clean all input. If you must preserve special characters and formatting then you must also escape output. Output escaping is non-trivial and depends on the context of the output (e.g. in a link, in an anchor, in ...


3

The other way to get hold of another window is to pop it up. You can specify the window name in the second parameter: var victim= window.open('http://example.com/vulnerable', '<script>alert("boom");<\/script>');


3

The OWASP XSS Experimental Minimal Encoding Rules suggest that all that needs to be encoded are <, & and >, as long as the charset is specified. Assuming the second page outputs within an HTML context, then there doesn't seem to be an XSS attack vector in this case. Setting charset and then encoding your POST will simply mean that the server will ...


2

There have been issues with filter_var when used with FILTER_VALIDATE_EMAIL in the past, however I cannot find any vulnerabilities with FILTER_VALIDATE_IP. Even though an IP address does not contain characters that have special meaning within HTML (e.g. <) or have characters that can break out of a database query (e.g. '), I would treat the value like ...


2

With an XSS attack you normaly try to put JavaScript Code on a website. In your example a user tries to log in and on the next page there may be a warning like 'Username [input string] is not valid'. Now if you try to log in as alert(‘XSS attack’) it would not be considered as a xss attack because the browser doesn't even recognizes your input as ...


1

Yes, if a path containing script tags is resolved to the page containing this code on your server (for example, via a rewrite rule) then script could be rendered in your page. This will be DOM based XSS as it will be your client-side code that is adding the script tag. e.g. https://www.example.com/foo/bar/<script>alert('foo')</script>


1

You would normally be correct, however you cannot protect against this MITM vulnerability even if you use a secure cookie over SSL. This cookie could still be MITM'd to inject XSS. The pen test report is correct - the fact that the XSS mechanism is a cookie gives rise to the MITM vulnerability. This is because the Same Origin Policy for cookies does not ...


1

A very simple explanation: Reflected XSS: The attack payload is included in a parameter when the victim follows a URL to the site. Stored XSS: The attack payload is stored in the site itself and when anyone visits the page, regardless of the URL followed, the attack executes.


1

Storing sensitive data in a cookie is not necessarily unsafe, it depends how you configure the cookie. Te cookie needs to be configured as a secure cookie (limited to HTTPS only), HttpOnly flag should be set to avoid cross side scripting (the cookie will not be available from javascript) and the domain must be set to the correct value depending on the scope ...


1

The method .text() seems more adequate/safer to solve the functional requirement of echoing the window.name in the page DOM. <script> $("div").text(window.name); </script> from jquery docs: http://api.jquery.com/text/ We need to be aware that this method escapes the string provided as necessary so that it will render correctly in HTML. ...


1

HTTP headers are like any other user data, and should be sanitized by webapplications. You might be able to use it to XSS yourself when you go to a "whats my ip" kind of website that displays this kind of information, if it's been built by developers who assumed HTTP headers are OK to send back to the user. I've seen happen in a webapplication to view logs ...


1

The ExternalInferface.call() is designed for invoking javascript, so this function as written effectively gives you the opportunity to invoke arbitrary javascript in the execution context of the website, which is already a serious security hole. http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00001039.html How specifically to exploit it? ...



Only top voted, non community-wiki answers of a minimum length are eligible