Vulnerability Testing of Web Applications with Burp Suite

27 March 2023 30 minutes Author: Endpool

Burp Suite: A powerful tool for testing the security of web applications

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.

Target site map

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.

In the window on the left we see the URL of the resources. The window on the right has the following columns, here are the most important of them:

– 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

Include in the sphere

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.

Exclude from the scope of application

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.

Identifying problems

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.

 

Proxy interception

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.

History of HTTP

The history of requests is almost the same as what you have in your browser.

 

Filter. Allows you to filter the history according to the following parameters:

– 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.
– Annotation.
– Listener. TCP port.

History of WebSockets

An analogue of HTTP history, but refers to the WebSockets protocol. You can read in more detail at wiki.

Proxy listener options

A listener that receives HTTP traffic from the browser. It is necessary to configure the browser in order to work with Burp

Interception of customer requests

Allows you to choose which client requests will be intercepted by Burp.

Interception of server responses

Allows you to choose which client responses Burp will intercept.

 

Intercepting WebSockets messages

Allows you to choose which WebSockets messages Burp will intercept. Possible messages: – Client -> Server; – Server <- Client.

Answer modifications

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 client-side validation of forms using JavaScript
– Remove all JavaScript
– Remove all tags

Match and replace

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
– Comment.

TLS Pass Through

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.

Miscellaneous

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

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.

Positions

  • This tab is used to configure the request pattern for the attack, as well as payload tokens and attack type (which defines the way payloads are assigned to payload positions).
  • In this example, you can see that the user, pwd, and cookie parameters will change to certain values during the attack. What exactly will change will be determined in the next tab – Payloads.

Attack Type – type of attack, there are 4 types:

  • Sniper. A single payload set is used here. It targets each payload position in turn and places each payload in that position in turn. This type of attack is useful for specifying individual query parameters for common vulnerabilities;
  • Battering Ram. One payload set is used for this. It iterates through the payloads and places the same payload in all defined payload positions simultaneously. This type of attack is useful when the attack requires inserting the same input in multiple places in the query;
  • Pitchfork. Uses multiple sets of payloads. For each defined position there is a separate set of payloads (maximum 20). The attack iterates through all payload sets simultaneously and places one payload at each specified position. In other words, the first request places the first payload from payload set 1 in position 1, and the first payload from payload set 2 in position 2; the second request will place the second payload from payload set 1 at position 1, and the second payload from payload set 2 at position 2, etc. This type of attack is useful when the attack requires different but related inputs to be injected at multiple locations within the request (for example, a username in one parameter and a known identification number corresponding to that username in another parameter);
  • Cluster bomb. Several sets of payloads are used for this. For each defined position there is a separate set of payloads (maximum 20). The attack repeats each set of payloads in turn to test all permutations of payload combinations. That is, if there are two payload positions, the attack will place the first payload from payload set 2 in position 2 and iterate over all payloads in payload set 1 in position 1; it will then place a second payload from payload set 2 at position 2 and iterate over all payloads into payload set 1 at position 1. This type of attack is useful when the attack requires different unrelated or unknown data to be inserted in multiple places in the request (eg while guessing credentials, username in one parameter and password in another parameter).

Payload

Here we can configure sets of values that will be substituted for each of the values specified by the user in the Positions block.

Payload sets

Here, the payload sets used in the attacks are chosen according to the type.

Payload parameters

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:

  •  Simple list. This is the simplest type of payload, allowing you to configure a simple list of strings used as payloads.
  • Runtime file. This type of payloads allows you to configure a file from which to read the payload lines at runtime. This is useful when a very large list of payloads is needed to avoid keeping the entire list in memory. One payload is read from each line of the file, so payloads may not contain newline characters;
  • Custom iterator. This type of payloads allows you to configure multiple lists of items and generate payloads using all permutations of the items in the lists. It provides a powerful way to generate custom permutations of characters or other elements according to a given pattern.
  • Character substitution. This type of payloads allows you to customize a list of strings and apply different character substitutions to each element. This can be useful in password-guessing attacks, to generate common variants of dictionary words.
  • Numbers. This payload type generates numeric payloads in a given range and in a given format.
  • Dates. This payload type generates payloads containing a date within a specified range and in a specified format.
  • Username generator. This type of payload allows you to configure a list of names or email addresses and retrieve potential usernames from them using various common schemes.

 

Payload processing

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.

The window for adding rules is shown below:

Possible rules:

  • Add prefix. Add a prefix before the payload;
  • Add suffix. Add a suffix after the payload;
  • Match/Replace. Replacing any parts of the payload that match a certain regular expression for a certain period of time;
  • Substring. Extraction of part of the payloads, starting from the specified offset (indexed 0) and up to the specified length;
  • Reverse substring. Functions as a substring rule, but the end offset is specified backwards from the end of the payload, and the length is counted back from the end offset.
  • Modify case. Modifies payload register if possible. The following options are available:
    – No change. Unchanged;
    – To lower case. Lower case;
    – To upper case. Bringing to the upper case;
    – To Propername. Bringing the first letter to the upper case, other letters are brought to the lower case;
    – To ProperName. Bringing the first letter to the upper case, other letters are not changed.
  • Encoding. Payload encoding using different schemes: URL, HTML, Base64, ASCII hexadecimal or other strings for different platforms;
  • Decoding. The process is the reverse of Encoding;
  • Hash – performs a hashing operation on the payload;
  • Add raw payload – this adds the raw payload value before or after the current processed value, i.e. the payload list is modified and another value is inserted to be checked later. This can be useful, for example, if you need to serve the same payload both raw and hashed;
  • Skip if matches regex. This checks if the current value matches the given regular expression, and if so, skips the payload and moves on to the next one. This can be useful, for example, if you know that a parameter value must have a minimum length and want to skip any values in the list that are shorter than that length.
  • Invoke Burp Extension. Call the Burp extension to process the payload. The extension must have a registered payload processor, Intruder. You can select the desired processor from the list of available processors that have been registered by the current payloads.

Payload encoding

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.

Resource pool

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:


Save options

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.

Request headers

Ability to configure update of values in HTTP headers during an attack, namely: – Content-Length; – Set Connection.

Error handling

Ability to configure behavior in case of network problems, namely: – Number of attempts in case of network error; – Pause between attempts

Results of the attack

Configuring the information to be displayed in the attack results, namely:

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.

Grep – Match

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.

In addition to the list of expressions to match, the following options are available:

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.

Grep – Extract

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.

Grep – Payloads

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.

Redirection

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.

The following options are available:

-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.

Repeater

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:

  • Controls for submitting requests and navigating the request history.
  • The target server the request will be sent to is shown – you can click on the target details to change them.
  • An HTTP message editor containing the request to be issued. You can edit the request and resubmit it again and again.
  • An HTTP message editor showing the response received from the last request sent.

Decoder

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.

Different transformations can be applied to different parts of the data. The following decoding and encoding operations are available:

  • URL;

  • HTML;

  • База64;

  • ASCII hex;

  • Hex;

  • Octal;

  • Binary;

  • GZIP

Additionally, various generic hashing functions are available depending on the capabilities of your Java platform.

Comparer

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:

  • When searching for username enumeration conditions, you can compare responses to failed logins using valid and invalid usernames, looking for subtle differences in the responses.
  • When an attack results in very large responses with different lengths than the base response, you can compare them to quickly see what the differences are.
  • By comparing sitemaps or proxy history records generated by different types of users, you can compare pairs of similar requests to see where the differences are that cause applications to behave differently.
  • When testing for blind SQL injection errors with boolean conditional injection and other similar tests, you can compare two responses to see if injecting different conditions resulted in a corresponding difference in response.

Logger

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:

  • Investigating what happened if Burp Suite produces unexpected results.
  • View details of what Burp Suite sends when your work involves handling sessions.
  • Making sure that long-running ongoing tasks (such as background scans) are still running.
  • Analysis of any issues that require visibility into what Burp Suite is doing.

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:

  • The datetime is in ISO 8601 format with a UTC offset: yyyy-MM-dd’T’HH:mm:ss.SSS’Z’.
  • Binary data (for example, HTTP/2 requests and responses) is represented as Base64-encoded strings.
  • Any data that contains commas is escaped by wrapping the data in double quotes. e.g. a,b will become “a,b”.
  • Any data containing double quotes is escaped with an additional double quote, e.g. “a” will become “””a”””.
  • Any data that begins with -, +, =, or @ is escaped to Excel by prefixing it with a single quote (‘).

We learned a little theory, and now we can learn more theory…

Let’s get to know OWASP

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.

  • Tools and resources
  • Community and network
  • Education and training

OWASP Top 10

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.

A little history of the popularity of vulnerability types.

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.

Practicing with Burp: OWASP Juice Shop

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!

Practicing with Burp: Installing Juice Shop locally

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!

Other related articles
ServicesSoft
Read more
Hacking wireless networks
The main advantage of wireless networks, as well as their Achilles' heel, is the availability of the physical medium of data transmission - radio air.
367
ServicesSoft
Read more
Hacking web servers
Users usually turn to the Internet to get information and buy products and services. For this purpose, most organizations have websites. Most websites store valuable information such as credit card numbers, email addresses and passwords, etc. This made them a target for attackers.
362
Found an error?
If you find an error, take a screenshot and send it to the bot.