XML is a markup language that is commonly used in web development. It is used for storing and transporting data. So, today in this article, we will learn how an attacker can use this vulnerability to gain the information and try to defame web-application.

XXE Testing Methodology:

• Introduction to XML
• Introduction to XXE Injection
• Impacts
• XXE for SSRF
  • Local File
  • Remote File
• XXE Billion Laugh Attack
• XXE using file upload
• Remote Code Execution
• XSS via XXE
• JSON and Content Manipulation
• Blind XXE
• Mitigation Steps

Introduction to XML

What are XML and Entity?

XML stands for “Extensible Markup Language”,It is the most common language for storing and transporting data. It is a self-descriptive language. It does not contain any predefined tags like <p>, <img>, etc. All the tags are user-defined depending upon the data it is representing for example. <email></email>, <message></message> etc.

• Version: It is used to specify what version of XML standard is being used.
  • Values: 1.0
• Encoding: It is declared to specify the encoding to be used. The default encoding that is used in XML is UTF-8.
  • Values: UTF-8, UTF-16, ISO-10646-UCS-2, ISO-10646-UCS-4, Shift_JIS, ISO-2022-JP, ISO-8859-1 to ISO-8859-9, EUC-JP
• Standalone: It informs the parser if the document has any link to an external source or there is any reference to an external document. The default value is no.
  • Values: yes, no

What is an Entity?

Like there are variables in programming languages we have XML Entity. They are the way of representing data that are present inside an XML document. There are various built-in entities in XML language like &lt; and &gt; which are used for less than and greater than in XML language. All of these are metacharacters that are generally represented using entities that appear in data. XML external entities are the entities that are located outside DTD.

The declaration of an external entity uses the SYSTEM keyword and must specify a URL from which the value of the entity should be loaded. For example

In this syntax Ignite is the name of the entity,

SYSTEM is the keyword used,

URL is the URL that we want to get by performing an XXE attack.

What is the Document Type Definition (DTD)?

It is used for declaration of the structure of XML document, types of data value that it can contain, etc. DTD can be present inside the XML file or can be defined separately. It is declared at the beginning of XML using <!DOCTYPE>.

There are several types of DTDs and the one we are interested in is external DTDs. 

SYSTEM: The system identifier enables us to specify the external file location that contains the DTD declaration.

PUBLIC: Public identifiers provide a mechanism to locate DTD resources and are written as below −

As you can see, it begins with the keyword PUBLIC, followed by a specialized identifier. Public identifiers are used to identify an entry in a catalog.

Introduction to XXE

An XXE is a type of attack that is performed against an application in order to parse its XML input. In this attack XML input containing a reference to an external entity is processed by a weakly configured XML parser.  Like in Cross-Site Scripting (XSS) we try to inject scripts similarly in this we try to insert XML entities to gain crucial information.

It is used for declaration of the structure of XML document, types of data value that it can contain, etc. DTD can be present inside the XML file or can be defined separately. It is declared at the beginning of XML using <!DOCTYPE>.

There are several types of DTDs and the one we are interested in is external DTDs. There are two types of external DTDs:

1. SYSTEM: System identifier enables us to specify the external file location that contains the DTD declaration

In this XML external entity payload is sent to the server and the server sends that data to an XML parser that parses the XML request and provides the desired output to the server. Then server returns that output to the attacker.

Impacts

XML External Entity (XXE) can possess a severe threat to a company or a web developer. XXE has always been in Top 10 list of OWASP. It is common as lots of website uses XML in the string and transportation of data and if the countermeasures are not taken then this information will be compromised. Various attacks that are possible are:

• Server-Side Request Forgery
• DoS Attack
• Remote Code Execution
• Cross-Site Scripting

The CVSS score of XXE is 7.5 and its severity is Medium with –

• CWE-611: Improper Restriction of XML External Entity.
• CVE-2019-12153: Local File SSRF
• CVE-2019-12154: Remote File SSRF
• CVE-2018-1000838: Billion Laugh Attack
• CVE-2019-0340: XXE via File Upload

Performing XXE Attack to perform SSRF:

Server-Side Request Forgery (SSRF) is a web vulnerability where the hacker injects server-side HTML codes to get control over the site or to redirect the output to the attacker’s server. File types for SSRF attacks are –

Local File:

These are the files that are present on the website domain like robots.txt, server-info, etc. So, let’s use “bWAPP” to perform an XXE attack at a level set to low.

Now we will fire up our BurpSuite and intercept after pressing Any Bugs? button and we will get the following output on burp:

We can see that there is no filter applied so XXE is possible so we will send it to the repeater and there we will perform our attack.  We will try to know which field is vulnerable or injectable because we can see there are two 0 fields i.e., login and secret.

So, we will test it as follows:

In the repeater tab, we will send the default request and observe the output in the response tab.

It says “bee’s secret has been reset” so it seems that login is injectable but let’s verify this by changing it from bee and then sending the request.

Now again we will be observing its output in response tab:

We got the output “ignite’s secret has been reset”  so it makes it clear that login is injectable. Now we will perform our attack.

Now as we know which field is injectable, let’s try to get the robots.txt file. And for this, we’ll be using the following payload –

Understanding the payload

We have declared a doctype with the name “reset” and then inside that declared an entity named “ignite”. We are using SYSTEM identifier and then entering the URL to robots.txt. Then in login, we are entering “&ignite;” to get the desired information.

After inserting the above code, we will click on send and will get output like below in the response tab:

We can see in the above output that we got all the details that are present in the robots.txt. This tells us that SSRF of the local file is possible using XXE.

So now, let’s try to understand how it all worked. Firstly, we will inject the payload and it will be passed on to the server and as there are no filters present to avoid XXE the server sends the request to an XML parser and then sends the output of the parsed XML file. In this case, robots.txt was disclosed to the attacker using XML query.

Remote File:

These are the files that attacker injects a remotely hosted malicious scripts in order to gain admin access or crucial information. We will try to get /etc/passwd for that we will enter the following command.

After entering the above command as soon as we hit the send button we’ll be reflected with the passwd file !!

XXE Billion Laugh Attack-DOS

These are aimed at XML parsers in which both, well-formed and valid, XML data crashes the system resources when being parsed. This attack is also known as XML bomb or XML DoS or exponential entity expansion attack.

Before performing the attack, lets know why it is known as Billion Laugh Attack?

“For the first time when this attack was done, the attacker used lol as the entity data and the called it multiple times in several following entities. It took exponential amount of time to execute and its result was a successful DoS attack bringing the website down. Due to usage of lol and calling it multiple times that resulted in billions of requests we got the name Billion Laugh Attack”

Before using the payload lets understand it:

In this, we see that at 1 we have declared the entity named “ignite” and then calling ignite in several other entities thus forming a chain of callbacks which will overload the server.  At 2 we have called entity &ignite9; We have called ignite9 instead of ignite as ignite9 calls ignite8 several times and each time ignite8 is called ignite7 is initiated and so on. Thus, the request will take an exponential amount of time to execute and as a result, the website will be down.

Above command results in DoS attack and the output that we got is:

Now after entering the XML command we will not see any output in response field and also bee box is not accessible and it will be down.

XXE Using File Upload

XXE can be performed using the file upload method. We will be demonstrating this using Port Swigger lab “Exploiting XXE via Image Upload”. The payload that we will be using is:

Understanding the payload: We will be making an SVG file as only image files are accepted by the upload area. The basic syntax of the SVG file is given above and in that, we have added a text field that will

We will be saving the above code as “payload.svg”. Now on portswigger, we will go on a post and comment and then we will add the made payload in the avatar field.

Now we will be posting the comment by pressing Post Comment button. After this, we will visit the post on which we posted our comment, and we will see our comment in the comments section.

Let’s check its page source in order to find the comment that we posted. You will find somewhat similar to what I got below

We will be clicking on the above link and we will get the flag in a new window as follows:

This can be verified by submitting the flag and we will get the success message.

Understanding the whole concept: So, when we uploaded the payload in the avatar field and filled all other fields too our comment was shown in the post. Upon examining the source file, we got the path where our file was uploaded. We are interested in that field as our XXE payload was inside that SVG file and it will be containing the information that we wanted, in this case, we wanted”/etc/domain”. After clicking on that link, we were able to see the information.

XXE to Remote code Execution

Remote code execution is a very server web application vulnerability. In this an attacker is able to inject its malicious code on the server in order to gain crucial information. To demonstrate this attack I have used XXE LAB. We will follow below steps to download this lab and to run this on our Linux machine:

In our terminal we will get somewhat similar output as following:

Now once it’s ready to be use we will open the browser and type: http://192.168.33.10/ and we will see the site looks like this:

We will be entering our details and intercepting the request using Burp Suite. In Burp Suite we will see the request as below:

We will send this request to repeater and we will see which field is vulnerable. So, firstly we will send the request as it is and observe the  response tab:

We can notice that we see only email so we will further check with one more entry to verify that this field is the vulnerable one among all the fields.

From the above screenshot it’s clear that the email field is vulnerable. Now we will enter our payload:

Lets understand the payload before implementing it:

We have created a doctype with the name ”root” and under that, we created an entity named “ignite” which is asking for “expect://id”. If expect is being accepted in a php page then remote code execution is possible. We are fetching the id so we used “id” in this case.

And we can see that we got the uid,gid and group number successfully. This proves that our remote code execution was successful in this case.

 

XSS via XXE

Nowadays we can see that scripts are blocked by web applications so there is a way of trespassing this. We can use the CDATA of XML to carry out this attack. We will also see CDATA in our mitigation step. We have used the above XXE LAB to perform XSS. So, we have the same intercepted request as in the previous attack and we know that the email field is vulnerable so we will be injecting our payload in that field only. Payload that we gonna use is as below:

Understanding the payload: As we know that in most of the input fields < and > are blocked so we have included it inside the CDATA. CDATA is character data and the data inside CDATA is not parsed by XML parser and is as it is pasted in the output. 

Let’s see this attack:

We will enter the above command in between the email field and we will observe the output in the response tab.

We can see that we have got the image tag embedded in the field with our script. We will right-click on it and select the option “Show response in browser”

We will copy the above link and paste it in the browser and we will be shown an alert box saying “1” as we can observe in the below screenshot.

So, the screenshot makes us clear that we were able to do Cross-Site Scripting using XML.

JSON and Content Manipulation

JSON is JavaScript Object Notation which is also used for storing and transporting data like XML. We can convert JSON to XML and still get the same output as well as get some juicy information using it. We can also do content manipulation so that XML can be made acceptable. We will be using WebGoat for this purpose. In WebGoat we will be performing an XXE attack.

We can see that the intercepted request looks like above. We will change its content-type and replace JSON with XML code. XML code that we will be using is:

We will be observing that our comment will be posted with the root file.

So in this, we learnt how we can perform XML injection on JSON fields and also how we can pass XML by manipulating its content-type.

Let us understand what happened above:

JSON is the same as XML language so we can get the same output using XML as we will expect from a JSON request. In the above, we saw that JSON has text value so we replaced the JSON request with the above payload and got the root information. If we would have not changed its content type to application/XML then our XML request would not have been passed.

Blind XXE

As we have seen in the above attacks we were seeing which field is vulnerable. But, when there is a different output on our provided input then we can use Blind XXE for this purpose. We will be using portswigger lab for demonstrating Blind XXE. For this, we will be using burp collaborator which is present in BurpSuite professional version only. We are using a lab named “Blind XXE with out-of-band interaction via XML parameter Entities”. When we visit the lab we will see a page like below:

We will click on View details and we will be redirected to the below page in which we will be intercepting the “check stock” request.

We will be getting intercepted request as below:

We can see that if we normally send the request we will get the number of stocks. Now we will fire up the burp collaborator from the burp menu and we will see the following window.

In this, we will press the “copy to clipboard” button to copy the burp subdomain that we will be using in our payload.

Payload that we will be using is as below:

Now we will see in Burp Collaborator, we will see that we capture some request which tells us that we have performed Blind XXE successfully.

We will also verify that our finding is correct and we will see in the lab that we have solved it successfully.

 

Mitigation Steps

• The safest way to prevent XXE is always to disable DTDs (External Entities) completely. Depending on the parser, the method should be similar to the following:

• Also, DoS attacks can be prevented by disabling DTD. If it is not possible to disable DTDs completely, then external entities and external document type declarations must be disabled in the way that’s specific to each parser.
• Another method is using CDATA for ignoring the external entities. CDATA is character data which provides a block which is not parsed by the parser.

Author : Naman Kumar is a  cyber security enthusiast who is trying to gain some knowledge in the cybersecurity field. Contact Here

After reading both of our previous articles, you might be wondering, “What about the other features or sections that Burpsuite’s Intruder offers us?” or “How can we use the other payload options rather than the Simple list only?”

So today, in this article, you’ll get all of your questions answered, whether it’s regarding the payload option, the attack type or even the grep match or grep extract values.

Table of Content

• Fuzzing with the Attack Type
  • Cluster Bomb
  • Battering ram
  • Pitchfork
• Fuzzing with the Payload Types
  • Brute forcer
  • Character Frobber
  • Case Modification
  • Numbers
  • Username Generator

Fuzzing with the Attack Type

Up till now, you might have seen that over in all the attacks scenarios, we’ve used Sniper as an attack type. We did this because sniper uses a single set of payloads and targets a single position in turn with it. But, with this, we can’t set multiple payload positions over in the same Request.

Thereby for such situation, where we need to set different input parameters as injection points, we can use the other attack types offered by Burpsuite.

So, let’s dig somewhat deeper and explore one of the most common attack types i.e. Cluster Bomb, here we’ll try to fuzz the username and password of the users by injecting two different payload lists respectively at the different injection points.

Cluster Bomb

Back with the similar way, let’s capture the ongoing HTTP Request and share it with the Intruder.

Now, let’s configure the payload positions by selecting the input values of login and password fields with the Add $ button. Therewith it, opt the Attack type to Cluster Bomb.

Time to fill the empty box with a list of all possible usernames.

Now, with the usernames, we need some passwords too. So, let’s configure payload 2 positions with all the possible password that can exist for a username.

As soon as we hit the “Attack” button, the fuzzer will start, and we’ll get the output screen having all the combinations of the usernames and passwords.

But wait, let’s first clear the background concept behind this, like how the two different payload lists will work such in order to give a successful 302 Redirection.

Here, in this attack, the first password from the payload list 2 will fuzz all the usernames from payload list 1, similarly, then the second password will fuzz all the usernames again and the attack goes on…. i.e. the next payload(password) from the payload list 2 will fuzz all the payloads(usernames) from payload list 1.

Therefore, the total number of requests generated in this attack is the product of the number of payloads in all defined payload sets.

Battering ram

The Battering ram attack type is most favourite of Bug Bounty Hunters, as it requires a single set of payload lists to hit the vulnerability at multiple positions within the request.

Here, a single list is injected at different payload positions i.e. it used where the same input is to be inserted in multiple places within the request.

Let’s make it more clear by manipulating the attack type to Battering ram within the captured request. Here, we’ll try to find out the accounts that are having their passwords as similar to their usernames.

Now, let’s inject some payloads by typing them at the input field. And then further, let’s start the attack by hitting the “Attack” button.

And there we go, we’re back with an output list. From the below image you can see that the total number of requests are equal to the number of payloads we injected. And with this, I don’t think so, that there is a need to sort the length or the status bars, as the output as “ignite” with 302 Redirection is clear.

Pitchfork

This attack type is completely different from all the other three, although it carries multiple payload sets and different injection points. But, it does not fuzz up the things, i.e. it simply checks the first payload from payload list one with the first payload from the payload list 2, and if they found to be the correct credential, it passes a success.

Let’s try it too, for the above-captured request that we’ve used. Simply manipulate the attack type to “Pitchfork” and mark the payload positions by selecting them and hitting the “Add” button.

Let’s do the same as we did it for Cluster Bomb, select the payload set and inject the payload lists.

In a similar manner, set the corresponding payloads in Payload set 2 for the payloads of list 1 i.e.

Now as soon as we hit the Attack button, in order to start the fuzz, we’ll be redirected to a new window, where we’ll have the successful login credentials.

Fuzzing with Payload Type

As we’re aware of this fact that the payload type in Burpsuite’s Intruder tab is designed to manage and create payloads as per our convenience. Although we’ve only used the Simple list option within it, there are a number of other lists too that are still hidden from our eyes. Let’s explore them one by one.

Brute forcer

Sometimes, people confuse up with the two terms fuzzing and brute-forcing, thereby in order to segregate the two, burpsuite has an inbuilt payload type as brute forcer, which takes the input string and generates payloads of specified lengths that contain all permutations of a specified input character set.

So, this time, we won’t specify any payload list, but rather we’ll configure burpsuite to make its own payloads and inject them at the mentioned payload positions.

Turn ON your burpsuite monitor and capture the HTTP request made by the Mutillidae’s login portal, and thereby share it to the intruder.

Now with this, we’ll fuzz the password field, as we did earlier select 123 as the injection point and set the attack type to Sniper.

Time to configure the most important thing, from the payload type option select Brute forcer and therewith it, fill up the empty input field.

Character Set – The set of characters that are to be used in payloads.

Min Length – The length of the shortest payload

Max Length – The length of the longest payload

Note :

The total number of payloads will be increased up with the size of the character set and the maximum length.

And at last, hit the Attack button. Sit back and relax because now the burp suite will do its work, it will create and match the payload with the username provided for the correct password.

Great !! From the below image you can see that we got the payload as “aa1” with 302 redirections, seems to be a successful one. Now, navigate at the top of the intruder tab and select Attack, there hit the pause button in order to pause the fuzzer.

Character Frobber

During a penetration test, there are times when we get encountered with such situations where a string is responsible for the application’s response, i.e. if we manipulate the string value with a valid one then the response will get altered. Such situations normally occur when we do an account takeover, where we try to manipulate the user ID with one of a genuine user.

But, if we try to manipulate the characters of the string manually, it may take up to weeks and months to find out a valid request, thereby in order to make our work easy, burpsuite offers an amazing payload type i.e. Character Forbber which modifies the value of each character position on the existing base string by incrementing the ASCII code of a specific character by one.

Now, back into the Mutillidae application, over at the left side of the dashboard, select OWASP 2017 > Broken Authentication & Session Management > Privilege Escalation > Via CBC- Bit Flipping and capture the request.

From the above image, we can see that a string is passing over into the URL, seems like its responsible for the user to have an application ID, User ID and group ID

Now, as soon as we capture the passing HTTP Request, we’ll directly share it to the intruder for further processing.

Let’s set our payload position to this passing string.

Time to opt, choose the payload type to Character frobber and select the operate on option to the “Base value of payload position”

Now, let’s make this attack somewhat more appealing with the use of the “Grep Extract” option, which will thereby help us in order to identify which payload sting is defined to which application ID.

Therefore, at the Options tab, scroll down to the Grep – Extract field, check the “Extract the following items from responses” and click on the “Add” button.

You’ll be redirected to a new window, click the fetch response button and the search for “Application ID” there, further select the output and hit OK, as in our case we’re having “A1B2”.

And there it is!! Hit the “Attack” button and initiate the fuzzer. (Rather than application ID, you can opt the User ID or the Group ID.)

Cool!! From the below image, we can see that we’ve successfully captured all the strings that correspond to a specific application ID.

In the output, you can notice that the payloads are almost similar to one another but there is an increment in the characters one after the other.

Numbers

Similar to the brute forcer, this payload type is specifically designed for the numbers part. Many bug hunters love this payload type as its acts as their helping hand majorly in the OTP Bypass attacks.

Although the method to use this payload is same, whether you use it for OTP bypass or login brute force.

So, let’s understand the working of this payload type by capturing the ongoing HTTP request of a login page.

As soon as we share it to the Intruder, we’ll thus need to set the positions for it, here let’s mark the password field and set the attack type to “Sniper”.

Choose Numbers from the payload type options provided and further configure the following as per your requirement.

From – The fuzzing will start from that payload.

To – The last Payload

Steps – This indicates the iteration, here I’ve set it to “1” i.e. the next payload after 100 will be 101, 102, 103 and so on. And if we set it “2”, then the next payload after 100 will be 102,104,106 with an increment of 2,

As soon as you set all these things, hit the “Attack” button and sit back and wait for the response. Within a few minutes, we’ll get a 302 Redirection at 123.

Case Modification

Sometimes it’s difficult to determine, that in which case the user has set his/her password. Thereby in order to solve this dilemma, burpsuite has a payload type integrated within itself, which adjust the cases (lower & upper) of the base value and create payloads within from that.

However, this is not for the passwords only, there are times when the developer blocks some specific cases for their input field, thereby in order to determine such, we can use this too.

Let’s capture the request and check its practical exposure.

You know what we need to do next, select the payload position and opt Sniper as an Attack type for it.

Now, here comes the best past. Opt Case modification from the provided list and configure the same.

Fill the empty box with an XSS script and hit the Attack button. (Here we’re testing for the XSS vulnerability as many times the developer blocks up “SCRIPT” or “script” keyword. )

Cool!! We got our payload injected at the correct place. Do a right-click, opt “Show Response in Browser” to check the same where Javascript is enabled.

And there we go, we got the pop up reflected with “1”.

Username generator

During a social engineering attack, its simple to gather information about the user whether it is his name or contact number, even there are times we can even guess up the password too, but the most difficult thing is to identify the username he set.

Therefore in order to get out of such situations, burpsuite offers one more great payload type, where we just need to give a specific name and it itself will generate all the possible usernames and check them according to the injected password.

Wonder, how this could be done?? Check out the following scenario.

Capture the Request with a random username and correct password and share it all to the Intruder.

Now, time to set our payload position, select “random” and click the Add button, further opt the attack type to Sniper.

And there we are, select “Username generator”, from the payload type and enter the name you wish for, for the usernames. Here, in our case, we’ve used “Ignite Technologies.”

We can even select the maximum number of payloads i.e. the usernames, here we’ve also set that to 50.

As soon as we hit the Attack button, our fuzzer will starts up and with this, we can see a huge number of usernames are there enrolled into the list, and we got ours as Ignite !!

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here

Over in the previous article, we learned about what fuzzing is and how the burpsuite helps us to fuzz a web-application, along with all these things we had even explored some great fuzzing payload lists that are offered by the burpsuite’s Intruder tab.

So, today, in this article we’ll investigate some other amazing pre-defined burpsuite’s payload lists that could thereby hit a crucial vulnerability.

Table of Content

• Fuzz with Burp’s built-in Payload lists
  • Fuzzing for Cross-Site Scripting
  • Fuzzing for OS Command Injection
  • Fuzzing for Hidden Directories
  • Fuzzing for HTTP Verb Tampering
  • Fuzzing for SQL Injection

• Fuzzing with Customized Lists.
  • Manipulate Burp Suite’s pre-defined payloads
  • Injecting our customized payload lists.

Fuzz with Burp’s built-in Payload lists

As we’re aware that burp suite comes with some pre-defined payload lists that can thereby help us in order to fuzz an application. However, we have already used a number of them in our previous article, so let’s make our hands wet again, by exploiting some more vulnerabilities with the remaining payload lists.

Fuzzing for Cross-Site Scripting

Cross-Site Scripting often abbreviated as “XSS” is a client-side code injection attack where malicious scripts are injected into trusted websites where the input-parameters are not properly sanitized or validated. You can learn more about Cross-Site Scripting from here.

However, such attacks are quite difficult when we try to exploit them with the bare hands, as they were secured up with some validations. Therefore, in order to exploit such validated applications, we need some fuzzing tools and thus for the fuzzing thing, we can count on BurpSuite’s Intruder tab.

Turn ON your Proxy service and capture the ongoing HTTP request with Burp Suite’s Intercept option, therewith it, share it all to the Intruder.

Let’s now configure the input parameters, hit the “Add” button to set the payload position with “ignite” and set the Attack type to “Sniper”.

 

Time to customize the most important thing i.e. the payload list, click on Add from list.. button and scroll until you get the “Fuzzing – XSS” option. Further, hit the “Attack” button to initiate the fuzzer.

And there we go, within a few minutes we’ll get the output list with all the success hits and drops. Double click on the length section to sort them out in the descending order.

Cool !! Now, share any of them to the browser in order to check the response is made.  And there it is, the browser hits our payload and showed up the response embedded within it as “XSS”

Fuzzing for OS Command Injection

OS Command Injection or Shell Injection is that vulnerability where the attacker tries to executes arbitrary commands directly through a vulnerable application, there in order to retrieve information of the webserver or try to make unauthorized access into the server. You can surf the complete vulnerability from here.

However, there is no such pre-defined list for this OS Command Injection but still, we can exploit it with the all-in-one fuzzing list i.e.  with “Fuzzing – quick”

As we did earlier, capture the request again and share it with the Intruder.

Further, lets set the injection point to “www.nsa.gov” by hitting the Add button and set the attack type to Sniper.

Let’s now opt the smallest and deadliest list to fuzz this injection point. And therewith that hit the “Attack” button to initiate the attack.

Within a few seconds, we’ll get our output. Alter the length section as in Descending order in order to analyse the responses.

There we go, the “;id” payload is working perfectly here.

Let’s check the same in the browser too. From the below screenshot you can see that our payload has been triggered out by the web-server.

Fuzzing for Hidden Directories

Similar to the web pages, there are some directories too that are hidden from the normal users, but yes they exist over the application.

However, it’s about to impossible to find these directories with the naked eyes. Therefore, to make our work easy and to make this task possible, burpsuite offers an amazing payload list that will drop out all the hidden directories within a few seconds. Thereby, this attack is also known as Web Directory Bruteforcing, you can check the same from here.

Over at the application, place a random keyword so that it would be easy to set out an injection point. As in our case, we’ve injected “abc” after the web application’s URL. Further, capture the Request and share the same to the intruder.

Now, here comes the role of our keyword, select it and hit the Add button.

Time to move further at our favourite step, select the Dictionary – short payload list from the Add from list… option.

As soon as we hit the Attack button, our fuzzing will get starts up and within a few minutes, we’ll be presented with a list of hidden files.

Seems like the Admin_files is having some juicy content, let’s check it out in the browser.

Fuzzing for HTTP Verb Tampering

HTTP Verbs are majorly used by web-developers while developing an application, during this phase they use the most common verb methods i.e. GET & POST. But rather than these two, there are a number of HTTP methods exists up, that if injected at a wrong place could thus lead to some drastic results.

However, in such attacks, the attacker manipulates up the HTTP method that was set up by the developer with an unwanted method, and if the output with the other HTTP method drops out with “200” Success, then the application might face some defacements.

Thereby in order to make this attack much simpler, burpsuite drops out an in-built payload list with all the HTTP Methods integrated within it. So let’s check it out about what it offers.

In a similar way, we did earlier, capture the ongoing HTTP Request and thus share it with the Intruder.

Now, this time we won’t set the payload position at the input values, but rather, we’ll set them up to the HTTP Request i.e. the “POST” method.

In the most simpler way, choose the payload list as “HTTP verbs”, and hit the Attack button.

Time to analyse, here we’ll see the “Status” section. We are testing the most vulnerable website, as the 200 success is with almost every HTTP method we set out.

Now, let’s check the response from the HEAD method, as we’re aware that a request with this method only shows up the Header part and hides up all the HTML code within it.

Fuzzing for SQL Injection

Over in our previous article, we had exploited an SQL suffering acuart’s login portal, there we used the Fuzzing – full list to accomplish the task, but Burp Suite is having a separate payload list specially designed to encounter an SQL vulnerability. So let’s try to use it here in this section.

Back with the similar way, intercept the request and share it with the Intruder.

Now, with this, let’s configure the injection points. Select “1” and “1” and then hit the Add button to set them as payload 1 and payload 2 respectively. But with all these things, don’t forget to change the Attack type to “Cluster Bomb” as there are 2 payloads.                                                     

I hope you know what we need to do next. Select the Fuzzing – SQL Injection for payload 1 from the options provided.

And then opt the same for Payload 2.

Before hitting the “Attack”  button, let’s make this fuzz more appealing by setting up the Grep Match value.

Note –

Here, we’ve used the phrase “Invalid credentials!” intentionally, as this is the error generated at when some wrong credentials are entered. So rather than “Invalid credentials!”, you have to set the one that displays as a part of an error message when you fails to get logs in.

Now, hit the “Attack” button in order to initiate the attack. And with that, we’ll get a list of all the payloads that can give a successful login.

Opt one and check its response in the browser.

Great !! And there we go, ”I wish I could have seriously taken that BLACK Pill !!”

Fuzzing with Customized Lists.

Manipulating Burp Suite’s pre-defined payloads

You might be wondering about, what, if I want to fuzz with my own payloads but along with that I also want the pre-defined lists.

However, the Burp suite developers might also have experienced the same thing too, thereby they designed a button called ADD with an input field where we can type and inject our payload along with the predefined lists.

So, let’s make it more clear by capturing an HTTP Request and sharing it with the Intruder.

Now, we know all the best things that we need to do next… Hit “Add $” at the selected text in order to set the injection point.

Let’s first select the predefined lists, here we’re using the most favourable list i.e. “Fuzzing – XSS”.

With this, let’s spice up the thing by injecting our customized payload as

<script>alert(“Ignite Technologies”)</script>

Time to find out our payload from the heap, and there it is, let’s give a right click and check its response in the browser.

It’s working !! We got “Ignite Technologies” being popped-out from the screen.

Injecting our Customised Payload Lists

We might have seen a number of payload lists all around over at the internet, so do we need to type the individual payload and hit the Add button in order to get that.

No !! As along with the pre-defined lists and the input field for the payloads, burp suite also provides an opportunity to take advantage of these things too.

Over at the left side above the Add button, we’re having one more button labelled as “Load”. This burp suite functionality helps us in the most amazing way it can, i.e. it allows us to load any payload list for our fuzzing attack.

Click on the Load button and select the payload list that you want to fuzz with.

As soon as we do so, the empty box will get filled up with all the strings that are within the list.

Time to start. Hit the Attack button and analyse the output it offers.

Let’s check the response for the selected one. Great !! From the below screenshot, we can see that the payload is working in the best way that it is designed to be.

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here