Tag Info

New answers tagged

1

From MDN: encodeURIComponent escapes all characters except the following: alphabetic, decimal digits, - _ . ! ~ * ' ( ) You would normally require a space character to add another attribute (such as onclick), unfortunately this will be encoded as part of the URI. However, from OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet: Unquoted ...


1

Error pages can have reflected XSS vulnerabilities too, especially when any error trace includes input parameters. If a vulnerable error page is served when the CSRF token is not present, then your CSRF protection does not prevent reflected XSS.


9

The answer is usually yes if the value is only reflected if a valid CSRF token is provided - the user can only "attack" themselves in this instance. However, if there is a form generated that correctly encodes output to a page that contains a CSRF token but then that form submits to a page that does not correctly encode output then your site is still ...


1

I would demonstrate a simple SQL injection, it's always nice to see the look on people's faces when you attack a website with a browser as your only weapon. Setup a simple site with a login page and then show them how you can expose the admins password by simply adding few characters to the url. After you get the admin's password delete the entire site. ...


0

The most important Things in this case is security. We want to give some HTML text from user or maybe by ourselves, then store it for exam in DB, then get it and show in webpages without fearing from any type of attack and misused by users with bad intention. I'v been researched about the best way to do that about 4 days and found 2 base ways. Please let me ...


1

Appscan has the "show in browser" feature that opens Appscans special "worst of all worlds" browser for the given vulnerability. If it isn't a false positive, this browser should execute the Javascript. I have found it a pretty reliable way to check for false positives. For all other testing, I've found that Firefox is the least protected from XSS, so I ...


0

There is the sand cat projet which provide a lot of pen testing tools, like scripting in lua, better view over the console and dynamic injection tools, and a lot of other good surprise.


3

When something like Burp finds an XSS vulnerability, I can't ever verify it when using something like TamperData. If you are already using Burp to find the vulnerability, why not use the intercepting proxy functionality to modify the request and to inject the XSS payload?


5

Your best bet would be mantra from OWASP: http://www.getmantra.com/ Contains a myriad of tools for penetration testing out of the box. Also open source should you need to add/modify anything.


8

Most browsers allow you to disable the function. For instance with chrome you need to start the browser using C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --args --disable-web-security For Firefox you have to go type about:config in the address bar. Then you need to set the browser.urlbar.filter.javascript to False. For Internet Explorer ...


0

I'd rather use JSON instead of XML. It is easier to understand how the parser works and so the security risks are much lower. For example you have to turn off loading external entities with libxml_disable_entity_loader(true) if you don't want an XXE attack, and so on. The other part of the question is the generation of HTML, SVG etc. in the browser. For ...


0

Improper escaping/encoding (which in this case leads to XSS vulnerability) could be exploited. The main condition which must occur is improper HTTP cache handling. If tested webapplication is vulnerable to HTTP cache poisoning, then your are able to exploit your XSS-finding. Attacker sends own Host header to the webapplication. Cache "saves" that ...


0

It's hard to say, if above code is fully secured, as you didn't provide us the definition of xml_encode function. Basing on your input/output samples, it looks, that xml_encode is similar to htmlspecialchars which could be used to sanitize your XML data too. If I were you, I'd decide to use htmlspecialchars with correct flags (ENT_QUOTES) or libraries for ...


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 ...


0

For SQL injection, you're basically on the right path. The best advice it to not roll your own. Use something well known; whichever language you're using probably has a library to be used with proper parametrised SQL. OWASP has a very good article including mitigations against this attack vector here If this string is never executable, then it's not a ...


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>


0

The encode() method HTML encodes characters, which is the correct XSS prevention method in this context. So if a " character was inserted inside of $str to try and break out of the HTML attribute context, this would be converted to &quot; or &#34; which is the HTML representation. Therefore it is not possible to inject script here, assuming encode ...


-1

If the web site is doing no escaping, validation, or character substitutions, the trivial XSS attack is just: " /> < script> alert('pawned') < / script> Which is why every web site should be doing escaping, validation, and substituting or removing dangerous characters.


0

I think the pen test team misspoke. MITM is a much more serious threat than a XSS, because the MITM attacker can monitor and replace any of the content of your site. It's invalid to complain about the content of a site attributing a MITM attack, because the content is irrelevant to a MITM. MITM can always inject content into your site. XSS is a ...


0

Man-in-the-middle might not be the only way to manipulate the cookie. If, for example, the cookie is used for example.org and you have subdomains like user1.example.org which you either don't control or which might have XSS problems, then it will be possible to set the cookie for example.org from user1.example.org. You will probably not be able to read it, ...


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 ...


0

It may be possible to bypass an XSS filter by either percent-encoding or HTML-encoding the characters that are being filtered. On the other hand, a properly-written filter is aware of these techniques and can handle them.


0

So let's say you navigate to www.example.com/page?main.html and it puts you on the main page of example.com. Now you navigate to the index, which is located at www.example.com/page?index.html. You start to wonder, what other pages are there? So you type in www.example.com/page?foo and hit enter, and you get an error page which will say something like ...


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.


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 ...


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 ...


0

You are right with all those issues. That implementation is not secure and could lead to identity theft. It is even less secure than using HTTP basic authentication as those cookies are vulnerable to XSS attacks. I could not think of any other issue apart from the ones you provided. (aren't they enough?). Well, there is the id of the entry of the user in ...


0

The address bar doesn't do anything. It's the web application which appearently takes the URL and inserts it right into the HTML markup, leading to a cross-site scripting vulnerability. This happens either server-side or client-side: Either the PHP script delivers the page with the URL already in it, or there's a piece of JavaScript code which injects the ...


0

That is the same as filling a form which has an input field named page with the following data text-file-viewer.php/"><script>alert("test");</script> If you get the alert pop-up, the server is writing the user input as is.


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. ...


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 ...


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 ...


0

DOM XSS are as dangerous as reflected XSS. To exploit it the attacker always needs to induce a client to create a request (f.e. by clicking some link that still points to the considered safe site). After this has been done, you can execure JavaScript on the client's browser. This can lead to all sort of attacks on the browser!


1

Your content is going into an HTML attribute, encoded in a URL. That gives you two possible forms of encoding: URL-encoding: %2F. Although this should in principle work, both IIS and Apache block the use of URL-encoded slashes due to some past security issues. HTML-encoding: &#47;, or rather as it is itself in a URL, %26%2347%3B. (Although... since ...


0

Remove the whole %20path=/ section - the HTTP response header should set everything at root level. If that doesn't work inside a meta http-eqiv, try the HTML encoded version of the path as because the content is in HTML should be correctly decoded (&#47;). Alternatively you could inject JavaScript to set the cookie via client-side script and set the ...


0

Try URL encoding the / character with the hex representation %2F.


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 ...



Top 50 recent answers are included