Issue:  
Possible DOM-based Cross-site scripting
Severity:  
High
Confidence:  
Tentative
Host:  
https://www.google.com
Path:  
/search
  
Note: This issue was generated by the Burp extension: Additional Scanner Checks.
Issue detail
The scanner check has detected occurrences of unsafe sources and sinks. If data flows from unsafe sources into unsafe sinks without being sanitized then it is quite certain that the web application is vulnerable against DOM-based XSS. See the response tab to review the occurrences.  
Issue background
DOM-based cross-site scripting (XSS) is a variant of the well-known XSS vulnerabilities where the issue is located in client-side JavaScript code. As in classical XSS, the vulnerability causes code execution in the context of the users session within the application. An attacker can perform a wide variety of actions, like session hijacking etc. The vulnerability is caused by copying data from non-trustworthy sources (user input, URL) into the DOM with insecure methods.
Such vulnerabilities are hard to detect with classical methods like checking the response for occurrences of previous inputs or parameters. This scan issue has detected the usage of insecure sources or sinks in the JavaScript code of the page. Further manual checks must be performed to verify the impact of their usage.
Issue remediation
DOM-based XSS can be prevented by usage of secure methods that only operate on the content text of the DOM instead of modifying the DOM structure. E.g. usage of the innerText attribute instead of innerHTML or the text() method of jQuery instead of html() to insert user content into the DOM. If these methods are not applicable in a particular use case, the user input has to be filtered and sanitized before it is passed into the DOM by insecure methods.

steps to exploit- (example)
1.client side code-
<script>
document.write("Site is at: " + document.location.href + ".");
</script>
An attacker may append #<script>alert('xss')</script> to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example, the code is immediately executed and an alert of "xss" is displayed by the page. Unlike the more common types of cross site scripting (Stored and Reflected) in which the code is sent to the server and then back to the browser, this is executed directly in the user's browser without server contact.

2. Then server may insert data into JavaScript
 var data = window.location;
    or
var result = someFunction(window.referer);

3. As it usually identifies XSS by sending a specific payload and attempts to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user:

<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>

Note- In attachment file I have already highlighted the words on which the exploitation worked.


 

Deleted: twitter.zip 163 KB

twitter.zip 163 KB Download