2

In the OWASP Testing Guide, it has a whole section called "Client-Side Testing." This section has to do with testing for things such as DOM-based XSS, JavaScript execution, HTML injection, Client-Side URL Redirect, etc. The examples in the testing guide for the first four vulnerabilities (the ones I just listed) all include code that access document.location.

My question is, what other ways are there for these kinds of vulnerabilities to be introduced into a web page without accessing document.location (or window.location or just plain location)? In other words, if a page does not ever access document.location, is it definitely free from these vulnerabilities? If not (and I'm sure it's not), could you please provide some other examples of vulnerable code?

0

If I understand your question. For the OWASP Client Side Testing list of vulnerabilities. You ask if for each vulnerability : If by exploiting the vulnerability you can't have access or use the document.location, the page is safe. The answer is no.

Indeed, take the example of the Open Redirect vulnerability. The vulnerability is accepted if you can redirect a legitimate user just with a link : http://www.victim.site?#redirect=www.fake-target.site You can see that the web site is vulnerable, the vulnerability is classified by OWASP as client side and we don't use or have access to document.location.

Let's take an example in full PHP. Imagine an Hello World web site without JavaScript. This is the code of the basic website :

<?php
if (isset($_GET['url'])){
  $redirectUrl = $_GET['url'];
  header("Location: $redirectUrl");
}else{
  echo "I am vulnerable to Open Redirect ! <br>";
  echo "Use the code <YOUR-SERVER>/vulnerable.php?url=http://www.duckduckgo.com to exploit me !";
}
?>

This code is vulnerable to Client Side URL Redirect. You can exploiting using this URL : <YOUR-SERVER>/vulnerable.php?url=http://www.duckduckgo.com.

However, you can't inject JavaScript or any other language so you can't have access to Document.location. Indeed, the vulnerability is in the PHP header and not in the object Location. Please, read the MDN Web docs page for more details.

4
  • This doesn't answer my question. My question was about what kind of code leads to the introduction of vulnerabilities that specifically fall under the "Client Side" OWASP category, not how those vulnerabilities can be exploited. In other words, what other code examples could they have included in the testing guide to demonstrate this kind of attack?
    – manny
    Apr 16 '20 at 10:36
  • I edited the answer, please say me if it doesn't respond the question. If it doesn't, please rephrase your question.
    – Anonyme
    Apr 17 '20 at 19:02
  • I edited the question because I'd like examples of vulnerable code that don't access document.location or window.location. The Open Redirect link you included has code in it that accesses the document's location (in this case, the window's location), so I still don't have any examples of vulnerable code that don't access either the document or window's location.
    – manny
    Apr 17 '20 at 20:10
  • I just edited my answer to add more details. Hope it will answer your question.
    – Anonyme
    Apr 18 '20 at 8:37
2

I am the current lead of the OWASP Web Security Testing Guide.

What you are asking for are sinks, which are mostly found in DOM XSS attacks.

Version 4.2 of the guide will be released next week. We have mentioned the term sinks, and to help further with your question, I will add references where possible. In versions to come, the team will add more to the topic to make it easier to read and understand, with more information in them.

Sources are the injection points, sinks take that input and manipulate either in a safe manner or in an abusive manner.

For more on what you're asking, the domxsswiki is a great read.

Update: PR related to this matter

1
  • 1
    Wonderful to have some authoritative answers here. Thanks for taking the time to contribute.
    – MechMK1
    Nov 26 '20 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.