Blog

  •

    How to perform SQL injection attacks

    4.59 of 66 votes

    SQL injections are one of the most popular server-side injection attacks. During an SQL injection attack, the attacker injects a malicious SQL query input. If the web application fails to sanitise that input, the query will be successfully executed on the server database and trigger an output response. These responses can vary, but most consist of error syntax leading to information leakage. Once an attacker possesses enough knowledge about the backend database table structure, they can inject specific commands to insert, update, and delete data within the database. If elements of an application communicate with a SQL database for authentication (such as login forms), a malicious query can also be leveraged to subvert the application logic. How SQL injection attacks work To explain how SQL injections work, I will use an example of a web application configured to require a username and password for authentication. This is typical of most web applications that have an SQL database on the backend. When a username and password is submitted via this login form, the web application takes this user input and queries the backend database to see if those credentials exist. The SQL query this user input generates will look something like this: This query commands the database to select any number of rows that match our conditions from users (where users is the table name), and then check the username and password columns for the user supplied input values. If the user supplied input values match those within the database, the SQL statement will be TRUE and the user will be logged in successfully. If any user supplied input values are incorrect, missing, or invalid, the SQL statement will be FALSE and the login will fail. It is important to remember that the SQL query is always generated by the web application and that the only control the user ever has (in this example) is over the username and password input values within it. This means an attacker is limited to what those fields accept when crafting a malicious string in effort to manipulate an SQL query. In this example, the objective of the attacker is to login successfully without knowing the user credentials. This means the focus of the attack will be to trick the SQL database into issuing a TRUE response to an attacker crafted query when attempting to login. OR logic gates To achieve this, an attacker can rely on an OR logic gate. An OR logic is a basic function that takes certain inputs and produces an output. The way this works can be illustrated via the simple A/B table below. This table shows that when rows A and B meet certain boolean conditions, the logic gate will produce a specific output. What is shown in this example is that the output TRUE is always consistent with TRUE inputs in any given row. This is irrespective of whether or not inputs within those rows also reflect FALSE. Putting it simply, the function of this logic gate defines any TRUE input as an overriding value which results in a TRUE output. Example To illustrate how this works in practice, I will be using the logic of this OR function in my SQL injection attack by amending the username value to the following: This query will return TRUE. The reason for this is because the first apostrophe closes the string parameter, and then the database takes the OR function and applies the 1=1 statement. As 1 is equal to 1, the database considers this part of the SQL statement TRUE. The purpose of the double hyphens is to comment out the rest of the SQL query, resulting in the database believing the conditions of the login are TRUE. This will result in the login being successful. Whilst this example demonstrates a single SQL injection string, it is important to remember that there is no universal string an attacker can leverage to craft a working malicious query. SQL databases typically differ greatly in format, size, and content, as do the defensive measures some web applications adopt to validate user input. The conditions that need to be satisfied for an SQL injection to be successful will depend entirely on how any target web application is built. Different SQL injection attack types There are two primary types of SQL injection attacks, error based and blind based. Error based attacks rely on inferences an attacker can make from specific errors produced by a web server whenever specific SQL statements are submitted to it. Blind based attacks are a form of indiscriminate fuzzing, where the expected application output is usually unknown. Responses (or lack thereof) produced by a web server to blind based attacks can enable an attacker to make informed determinations about the database structure, which – when combined with a carefully crafted SQL query, can amount to exploitation.   Prevention To prevent SQL injection attacks, the following layers of defence can be adopted: Special characters submitted as input such as ' and '' should be encoded before the web application passes them into an SQL query and special string characters used within input parameters should be escaped. Suspicious user inputs submitted should be checked against a predefined blacklist of strings and rejected wherever the same values are shared.

  • How to identify Path Traversal vulnerabilities

    4.78 of 68 votes

    Websites are made up of two types of file, those intended to be accessible by the browser (like JavaScript and CSS files), and those that are not. Web servers often route URLs to particular template files or assets on the file system. Typically, the layout of the files on the server mirror the URL structure of the website. A poorly configured web server can be too permissive about what files it returns and this can allow an attacker to access files which were never intended for public access. This may allow commands to be executed on the web server and data can be copied or modified. How does this work? For example, a website hosts a document at the https://jacobriggs.io/documents?files=whitepaper.pdf URL. An attacker visits this URL triggering a request to download the document via their browser. The attacker notices the name of the requested document is passed in the files parameter of the query string. Unfortunately, in this instance, the raw file name whitepaper.pdf is used in the download URL, so an attacker can abuse the files parameter to climb out of the directory that holds documents within the files location. An attacker can now craft a URL using relative path syntax ../ to explore the local file system.  If the normal file path URL is https://jacobriggs.io/documents?files=whitepaper.pdf then the instruction that is passed to the server when requesting this is to open the /etc/apache2/jacobriggs.io/documents/whitepaper.pdf location. If the attacker crafted URL is https://jacobriggs.io/documents?/files=../../../../ssl/private/private.key then the instruction that is passed to the server when requesting this is to access the /etc/ssl/private/private.key location. Since the server does not validate file paths, an attacker is now able to access sensitive files.   Tutorial For this example I will be using PortSwigger’s web security lab. To solve the lab, we must retrieve the contents of the /etc/passwd file. Whilst this is a rudimentary task and can be done without the need of automation, I will be using their lab environment to demonstrate Burp Suite tooling and common path traversal fuzzing techniques used in practice. First we open the lab environment website and navigate to a product listing. We view the source code of the web page and notice that the requested images are being passed in the filename parameter. We open up Burp, turn on Proxy > Intercept, and we request the image directly via its normal file path URL in our browser. We then check our captured HTTP GET request, and send the vulnerable parameter to Intruder. We then navigate to Intruder > Positions and we review the payload positions within the request template. We can see that the cookie session parameter within our base request is automatically assigned a payload position. This is not needed, as the current session will be sufficient for our attack, so we highlight and clear the entry. We then navigate to Intruder > Payloads to configure our attack. Under Payload Options we click Load and add the dotdotpwn.txt file which contains a list of common attack strings to help automate our fuzzing. Now we need to instruct Burp to identify which of our captured responses contain the strings we're interested in. We know that the passwd location is structured in the format of a standard user account table. We also know that this table always contains the user root within it. So we navigate to Intruder > Options and instruct Burp to flag any responses matching the root: string. As everything is now configured, we can navigate to Intruder > Target to double check we are targeting the correct host and initiate our attack. For each query sent within our payload parameters, Burp captures the responses. This is where we pay particular attention to any anomolies within the length of the responses, and any flags matching the root: string. We can see that request 9 is identified as a match, and that when viewing the server response the full structure of the passwd table format is returned. We have now achieved the path traversal attack by proving we can access the passwd file and content within it. Whilst this is a basic example, it demonstrates the simple risks associated with websites allowing the placement of user input in file paths.   Prevention To prevent path traversal vulnerabilities, it is important that web applications avoid passing arbitrary strings of user supplied input to filesystem APIs. Where passing arbitrary strings of user supplied input is necessary, two layers of defence can be adopted: User supplied input should be validated by the web application before processing it. This validation should compare against a whitelist of permitted values. Once user supplied input has been validated, the web application should append it to the base directory, ensure the path is canonical to the filesystem, and that the canonicalised path starts with the expected base directory. .

  • Welcome to my new blog

    • General
    • by Jacob Riggs
    • 02-01-2020
    4.19 of 64 votes

    My journey as a security researcher over the past decade has taught me a lot, but I know there’s still so much more to learn. I thought it might be worth creating this blog to document and share some of my personal experiences, and hopefully give something back to the thriving security community I’ve grown to be a part of. The term ‘InfoSec’ encompasses a myriad of fields that make up quite a bizarre industry, but one I’ve come to thoroughly enjoy exploring over the years. I've met some amazing people, and we've built (and broken) some incredible (and peculiar) things together. I think that documenting some of these events will enable me to better measure my personal development and maybe encourage a wider sharing of knowledge. With a little steady effort, I hope to eventually turn this blog into a valuable resource that myself and others can come to rely on when looking to learn and understand new things moving forward.