Burp Suite is a powerful web application vulnerability testing tool that helps to ensure a high level of security for your web application. It is a software complex that contains a set of tools designed to detect and exploit various types of vulnerabilities. Burp Suite allows you to perform security audits of web applications, intercept and analyze traffic between the client and the server, check for various types of vulnerabilities such as SQL injections, XSS attacks, CSRF attacks, and perform penetration testing. Burp Suite allows testing both manually and automatically, which allows for the most effective detection of vulnerabilities. In addition, the tool has the ability to configure special scripts to automate the testing process and identify vulnerabilities. Due to its capabilities, Burp Suite is an indispensable tool for development teams and testers involved in building and testing web applications.
Using this tool allows you to ensure a high level of security of web applications and reduce the risk of their vulnerability to a minimum. If you develop or test web applications, Burp Suite is a must-have tool. It will allow you to conduct effective vulnerability testing and ensure a high level of security for your web application. Today we’re going to take a look at the most important tools that make Burp’s life better. Burp has several tabs, let’s consider the most popular of them: Proxy; Intruder; Repeater Decoder; Loggers; Comparer. Let’s get acquainted with OWASP Top 10, OWASP Juice Shop. Let’s find out the most known categories of vulnerabilities, and let’s try exploiting one of them on our own experience using Juice Shop, a web application for developing vulnerability testing skills.
When you go to our site, you can see a kind of “map” of the site – all the links that Burp was able to find on the site. This greatly simplifies the analysis of this or that resource.
– Host. Domain
– Method. HTTP is a method for interacting with a resource. You can read here
– URL. A link found by Burp.
– Params. The box is checked if parameters have been added to the query.
In this case it is wc-ajax and elementor_page_id as shown in the screenshot below:
– Status. The status of the server’s response to the client’s request. You can read here
Here you can add targets that you want to track or penetration test. There is a corresponding button for each action: – Add. – Edit. – Remove. – Paste URL. Insert link; – Load... Download.
Here you can exclude from the scope goals that are not of interest to you at the moment. You can interact with this block using the corresponding buttons, which are described in the Include in scope block above.
Here you can see an explanation and description of the types of vulnerabilities. This table consists of three columns: – Name – The name of the vulnerability. – Typical severity- The level of “danger” of this vulnerability. – Type index- Index in this table.
One of Burp’s most popular features. Allows you to intercept both requests from the client (your browser) and server responses (the same pornhub page you want to open).
The most important buttons to stick to:- Forward. If Intercept is ON, this packet can be edited and forwarded. – Drop. Skip intercepted packet. – Intercept is on/off. Enable or disable packet capture – Open Browser. Open the browser is already configured to work with Burp.
The history of requests is almost the same as what you have in your browser.
– Request type:
– Only those that were added to the scope;
– Hide those that do not match;
– Only those with parameters.
– MIME Type. Data type
– Status Code. Response from the server.
– Search Term. Improved search with the possibility of using regular expressions.
– File extension. File types.
– Listener. TCP port.
An analogue of HTTP history, but refers to the WebSockets protocol. You can read in more detail at wiki.
A listener that receives HTTP traffic from the browser. It is necessary to configure the browser in order to work with Burp
Allows you to choose which client requests will be intercepted by Burp.
Allows you to choose which client responses Burp will intercept.
Allows you to choose which WebSockets messages Burp will intercept. Possible messages: – Client -> Server; – Server <- Client.
Allows you to choose the actions that will be performed automatically when modifying responses from the server. List:
– Show hidden form fields
– Replace the disabled parameter of form elements with enabled
– Remove restrictions on user input of data in the relevant fields
– Remove all tags
It is used to automatically replace data in client and server requests and responses. Interaction with this block is carried out using the corresponding buttons. The table has the following columns:
– Enabled. Displays whether the given pattern is currently in use;
– Item.The type of element to be replaced;
– Match. A regular expression of what we want to replace.
– Replace. The data we want to replace the Match result with.
– Type. The data type found in the Match column
These settings are used to specify target web servers to which Burp will go directly over a TLS connection. No information about requests or responses made over these connections will be available in the proxy’s browsing or interception history. Transmission over a TLS connection can be useful in cases where it is not easy to debug TLS errors on the client – for example, in mobile applications that perform TLS certificate pinning. If the application accesses multiple domains or uses a mix of HTTP and HTTPS connections, TLS connection forwarding to specific problem hosts still allows you to handle other traffic with Burp in the normal way.
These options control some specific details of Burp Proxy’s behavior. The following options are available: – Use HTTP/1.0 in requests to server. This option controls whether Burp Proxy will use HTTP version 1.0 in requests to target servers. The default setting is to use whatever version of HTTP is used by the browser. However, some legacy servers or applications may require version 1.0 to function correctly. – Use HTTP/1.0 in responses to clients. All current browsers support both HTTP versions 1.0 and 1.1. Because version 1.0 has a reduced feature set, forcing version 1.0 can sometimes be useful for controlling aspects of browser behavior, such as preventing HTTP pipelining attempts. – Set response header “Connection: close”. This option can also be useful to prevent HTTP pipelining in some situations. – Set “Connection: close” on incoming requests. This option can also be useful to prevent HTTP pipelining in some situations. – Strip Proxy-* headers in incoming requests. Browsers sometimes send request headers containing information specific to the proxy server being used. There are several attacks that a malicious website can use to try to force the browser to include sensitive data in these headers. By default, Burp Proxy removes these headers from incoming requests to prevent any information from being leaked. Unchecking this option will cause Burp to leave these headers unchanged. – Remove unsupported encodings from Accept-Encoding headers in incoming requests. Browsers usually offer to accept different encodings in responses, e.g. to compress the content. Some encodings cause problems when processing responses in Burp. By default, Burp removes unsupported encodings to make them less likely to be used. If the server requires support for an unsupported encoding, you may need to uncheck this option. – Strip Sec-WebSocket-Extensions headers in incoming requests. Browsers may offer support for various extensions related to WebSocket connections, e.g. to compress the content. Some encodings cause problems when processing responses in Burp. By default, Burp removes this header to reduce the chance of using extensions. If the server requires a certain extension, you may need to uncheck this option. – Unpack GZIP / deflate in requests. Some applications (often those using custom client components) compress the message body in requests. This setting controls whether Burp Proxy automatically decompresses compressed request bodies. Note that some programs may crash if they expect body compression and the compression has been removed by Burp. – Unpack GZIP / deflate in responses. Most browsers accept compressed GZIP in their responses. This option determines whether Burp Proxy automatically decompresses the compressed content of responses. Note that you can often prevent servers from trying to compress responses by removing the Accept-Encoding header from requests (perhaps using Burp Proxy’s match-and-replace feature). – Disable web interface at http://burp. This option can be useful if you need to configure a listener to accept connections to an insecure interface and want to prevent others from accessing the Burp interface in the browser. – Suppress Burp error messages in the browser. When certain errors occur, Burp returns an error message to the browser by default. If you want to run Burp in stealth mode to perform man-in-the-middle attacks against the victim user, then it may be useful to hide these error messages to mask the fact that Burp is running. – Don’t send items to Proxy history or live tasks. This setting prevents Burp from logging any requests in the proxy history or sending them to active tasks such as passive scanning or live auditing. This can be useful if you use the Burp proxy for specific purposes, such as authenticating to upstream servers or performing match-and-replace operations, and you want to avoid the memory and storage overhead that logging entails. – Don’t send items to Proxy history or live tasks, if out of scope. This option prevents out-of-scope requests from being written to the proxy history or sent to active tasks such as passive scanning or live auditing. It is useful to avoid accumulating project data for out-of-scope items.
Intruder is Burp Suite’s built-in fuzzing tool. This allows us to take a request (usually captured in the proxy before being sent to Intruder) and use it as a template to automatically send many requests with slightly modified values. For example, by capturing a request containing a login attempt, we could then configure Intruder to replace the username and password fields with values from a list of words, effectively allowing us to brute force the login form.
Fuzzing is an automated software testing technique that attempts to find breakable software bugs by randomly feeding invalid and unexpected inputs and data into a computer program to find coding errors and security holes.
Here the user can select a target to attack, which will apply the configuration described in the following tabs.
Here we can configure sets of values that will be substituted for each of the values specified by the user in the Positions block.
Here, the payload sets used in the attacks are chosen according to the type.
Loading a set of payloads. Here you can download from a file or write your own. It only applies to payloads of the Simple list type, but it’s also worth considering all the available payloads that Burp works with:
Here you can make additional payload settings, which will be performed automatically during the attack, just before the substitution.
All payload types supported by Burp can be used.
Performing the Encoding operation described above in the URL format. Any configured URL encoding is applied last, after any payload processing rules have been met.
Allows you to manage the following parameters during an attack: – Maximum number of requests made simultaneously; – Delay between requests, in milliseconds. There is an opportunity to make a fixed delay, randomized, or incremental.
An example is shown in the figure below:
Ability to save settings. Very useful if the Burp drawer is a work tool that you use every day, saving important settings can save quite a lot of time. Only available in the Pro version.
Ability to configure update of values in HTTP headers during an attack, namely: – Content-Length; – Set Connection.
Ability to configure behavior in case of network problems, namely: – Number of attempts in case of network error; – Pause between attempts
– Store requests. Storage of requests;
– Store responses. Saving answers;
– Make unmodified baseline request. Generating a request with normal parameters;
– Use DoS mode. According to the principle of DoS, Burp will not wait for the processing of any responses from the server;
– Store full payloads. Saving payload values for each result.
These parameters can be used to mark result elements that contain the specified expressions in the response. For each item configured in the list, Burp will add a new result column containing a number indicating how many times the expression was found in each response. You can click on a column header to sort the results by the number of expressions found.
– Match Type. Determines whether the expressions are simple strings or regular expressions.
– Case sensitive match. This specifies whether the expression validation should be case sensitive.
– Exclude HTTP headers. Specifies whether to exclude HTTP response headers from inspection.
These settings can be used to extract useful information from the responses into the attack result table. For each item configured in the list, Burp will add a new result column containing the text extracted for that item. You can then sort that column (by clicking the column header) to organize the extracted data. This option is useful for extracting data from an application and can support a wide range of attacks. For example, if you’re looping through a series of document IDs, you can extract the page title of each document, looking for items of interest.
These parameters can be used to specify result elements that contain a representation of the submitted payload. If this option is enabled, Burp will add a new results column that contains a number indicating how many times the payload was found in each response. If more than one payload set is used, a separate column will be added for each payload set.
These settings determine how Burp handles redirects when performing attacks. Redirects are often necessary to achieve the goals of your attack. For example, in a password guessing attack, the result of each attempt may only be displayed after a redirect. During fuzzing, the appropriate feedback can only appear in the error message returned after the initial redirection response.
-Follow redirections. This setting controls the redirect targets to follow.
-Process cookies in redirections. If this option is selected, all cookies set in the redirect response will be resent when the redirect target is reached. For example, you might want this option if you are trying to implement a rough login method that always returns a redirect to the login result page and a new session is created in response to each login attempt.
To use Burp Repeater with HTTP messages, you can select the HTTP message anywhere in Burp and select “Senr to Repeater” from the context menu. This will create a new request tab in Repeater and automatically populate the target details and request message editor with the appropriate details. Alternatively, you can manually open a new Repeater tab and select the “HTTP” option. For HTTP messages, each Repeater tab contains the following elements:
Burp Decoder is a simple tool to convert encoded data into its canonical form or to convert raw data into various encoded and hashed forms. It is able to intelligently recognize multiple encoding formats using heuristics.
Additionally, various generic hashing functions are available depending on the capabilities of your Java platform.
Burp Comparer — it’s a simple tool for comparing (visualizing the “difference”) between any two data items. Below are some common uses for Burp Comparer:
Logger — is a tool for recording network activity. Logger records all HTTP traffic generated by Burp Suite for research and analysis, but is particularly useful for:
Export of information from the logger in CSV format is also available. To export Logger entries as a CSV file, select the relevant entries in the table, right-click and select Export as CSV. Note that selecting zero or one record will export the entire table.
When exporting records in CSV format, Logger encodes certain data as follows:
Open Web Application Security Project® (OWASP) — is a non-profit foundation working to improve software security. Through community-driven open source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is a resource for developers and technologists to secure the Internet.
As an information security professional, you will hear this name very often, because it is a kind of standard. OWASP Top 10 is the standard for web application developers and security. It represents a broad consensus on the most critical security risks for web applications.
Companies should adopt this document and begin the process of transforming their development processes so that their web applications minimize the risks described in this standard. Using the OWASP Top 10 is probably the most effective first step in changing the software development culture in most organizations to one that produces more secure and reliable code. Top 10 Web Application Security Risks. There are three new categories, four categories with name and scope changes, and some consolidation in the Top 10 for 2021.
A01:2021-Broken Access Control. Access control enforces policies in such a way that users cannot act outside of their permissions. Misconfigurations of such configurations typically result in unauthorized disclosure, modification or destruction of all data, or performance of a business function beyond the user’s limitations.
A02:2021-Cryptographic Failures. Addresses data protection needs in transit and at rest. For example, passwords, credit card numbers, medical records, personal information and business secrets need additional protection, mainly if this data is subject to privacy laws such as the EU General Data Protection Regulation (GDPR) or regulations such as protection of financial data. for example, the PCI Data Security Standard (PCI DSS).
A03:2021-Injection. Some of the most common injections are SQL, NoSQL, operating system (OS) command execution, object-relational mapping (ORM), LDAP, and expression language (EL) or object graph navigation library (OGNL) injection. . The concept is identical among all tools. A source code review is the best method for detecting whether applications are vulnerable to injection. Automatic testing of all parameters, headers, URLs, cookies, JSON, SOAP and XML inputs is strongly encouraged.
Organizations can incorporate static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to detect injection flaws before deployment to production.
A04:2021-Insecure Design. Unsafe design is a broad category that represents various deficiencies expressed as “absent or ineffective control design.” Unsafe design is not the source of all the other 9 risk categories. There is a difference between insecure design and insecure implementation. We distinguish design flaws and implementation defects for a reason, they have different root causes and their elimination.
A protected design can still have implementation defects that lead to exploitable vulnerabilities. An insecure design cannot be remedied by a perfect implementation because, by definition, the required security controls were never designed to protect against specific attacks. One of the contributing factors to insecure design is the lack of a business risk profile specific to the software or system being developed, and thus the inability to determine what level of security design is required.
A05:2021-Security Misconfiguration. A program may be vulnerable if it has one of the following flaws:
– there is no appropriate security enhancement in any part of the program stack or incorrectly configured permissions for using cloud services;
– unnecessary features are enabled or installed (for example, unnecessary ports, services, pages, accounts or privileges);
– default accounts and their passwords remain active and unchanged;
– error handling exposes stack traces or other overly informative error messages to users.
– for updated systems, the latest security features are disabled or not reliably configured;
– security parameters on application servers, application frameworks (for example, Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values;
– the server does not send security headers or directives, or they are not set to secure values;
– the software is outdated.
A06:2021-Vulnerable and Outdated Components. An application is vulnerable if:
– If you don’t know the versions of all the components you use (both client-side and server-side). This includes components that you
use directly, as well as nested dependencies;
– If the software is vulnerable, unsupported or outdated. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtimes and libraries;
– If you do not regularly scan for vulnerabilities and subscribe to security bulletins related to the components you use;
– If you fail to patch or update the underlying platform, frameworks and dependencies in a timely and risk-aware manner. This typically occurs in environments where patching is a monthly or quarterly task under change control, leaving organizations exposed to days or months of unnecessary exposure to fixed vulnerabilities.
A07:2021-Identification and Authentication Failures. User authentication, authentication, and session management are critical to protecting against authentication-related attacks. There may be authentication flaws if the application:
– Enables automated attacks such as credential stuffing when an attacker has a list of valid usernames and passwords;
– Allows brute force or other automated attacks;
– Allows standard, weak or well-known passwords such as “Password1” or “admin/admin”;
– Uses weak or ineffective credential recovery and password recovery processes, such as “knowledge-based answers” that cannot be made secure;
– Uses plain text, encrypted or weakly hashed password stores;
– Missing or ineffective multi-factor authentication;
– Outputs the session ID in the URL;
– Reusing the session ID after a successful login;
– Incorrectly cancels session IDs. User sessions or authentication tokens (primarily single sign-on (SSO) tokens) are not properly revoked during logout or periods of inactivity;
A08:2021-Software and Data Integrity Failures. Software and data breaches refer to code and infrastructure that do not protect against breaches of integrity. An example of this is when an application relies on plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs).
An unsafe CI/CD pipeline can create the potential for unauthorized access, malicious code, or system compromise. Finally, many applications now have an automatic update feature, where updates are downloaded without sufficient integrity checks and applied to a previously trusted application.
Attackers can potentially download their own updates to distribute and run on all installations. Another example is when objects or data are encoded or serialized into a structure that an attacker can see and
change are vulnerable to dangerous deserialization.
A09:2021-Security Logging and Monitoring Failures. Returning to the OWASP Top 10 for 2021, this category should help detect, escalate and respond to active breaches. Without registration and monitoring, violations cannot be detected.
Inadequate registration, detection, monitoring and proactive response occurs anytime, here are some of the issues that exist:
– Auditable events such as logins, failed logins and high value transactions are not logged;
– Warnings and errors do not generate, inadequate or unclear log messages;
– Application logs and APIs are not monitored for suspicious activity;
– Logs are stored locally only.
A10:2021-Server-Side Request Forgery. SSRF errors occur whenever a web application retrieves a remote resource without validating the URL provided by the user. This allows an attacker to force an application to make a request to an unexpected destination, even if it is protected by a firewall, VPN, or other type of network access control list (ACL).
As modern web applications provide end-users with convenient features, retrieving a URL is becoming a common scenario. As a result, it grows incidence of RSD. In addition, the severity of SSRF becomes higher due to cloud services and complexity of architectures.
OWASP Juice Shop is probably the most advanced and sophisticated non-secure web application! It can be used in security training, demos, CTFs, and as a guinea pig for security tools! Juice Shop covers vulnerabilities from across the OWASP Top 10 along with many other vulnerabilities found in real applications!
In order to hit the enemy like the ZSU does with javelins, you need practice. So let’s install this shop and learn how to make cool stuff!
Let’s install Juice Shop. Instructions for little ones:
Let’s go here, and poke at GitHub*, and get there here, screenshot below to verify that you have come to the right place:
Next, click on <> Code and enter here:
Scroll down until you see the following:
Follow the instructions. Let’s install node.js:
Let’s create a folder for our juice shop:
Download the Juice Shop repository to this folder:
If you don’t have git installed, install it:
sudo apt-get install git
Let’s install npm:
Now let’s finally install Juice Shop:
Now, in order to get to the store, we need to “open” it (launch it):
In the screenshot above, you can see the port on which the server is running, so let’s go to this address in the browser:
We see that the site has successfully launched, so let’s start developing practical skills in using Burp. Let’s start it. Let’s go to the proxy and launch the browser by clicking on Open Browser. Then we will go to the login page in the browser from Burp.
Next, enable interception mode to intercept the login request.
Enter some data in the login and password fields, and click the Log in button. We will see the request that was sent to the Proxy.
We see that a POST request to the server is used. Let’s try to check this form for SQL injection. Let’s send this request to Repeater’y using CTRL+R. And after that, turn off the interception mode by clicking on “Intercept is on”.
After going to the repeater, let’s try to replace the email value with a single quote, as shown in the screenshot below. Then press CTRL + SPACE to send the request.
After that, we see that there is an SQL syntax error in the response from the server, and we see the original request.
This means that we can try to exploit this vulnerability. Edit the field as follows, and send a request to the server:
We see that an authorization token was sent to us, that is, we successfully logged in. Let’s go to the site and see how it looks in person. When you go to the browser, you can see 2 messages about the successful completion of the task:
Let’s try to log in to the browser using the data that was entered in Burp, and we can see that we have successfully exploited the SQL Injection vulnerability.
In this way, you can develop this attack vector by finding other vulnerabilities that belong to the OWASP Top 10 categories. Try it yourself and become a cool hacker to ensure the security of our country!