The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

FINDING COLUMNS WITH A USEFUL DATA TYPE IN AN SQL injection UNION attack!

DOCTOZip | Last updated: Mar 07, 2022 09:54PM UTC

Hello, I hope you are doing well and enjoying your time at PortSwigger. Today, when I was learning about SQL injection UNION attack, I have faced a problem dealing with what has been explained below. If anyone can explain it more, it would be great! Thank you so much in advance. Why using 'a' (in the example) as a name of a column which doesn't exist in the database's tables, won't provoke an error on the database system before it compares the data type of two values (with symmetrical indexes) in the SELECT list of the SQL queries? For instance:' UNION SELECT 'a', NULL, NULL-- (how did we know that 'a' exists as a column in the database tables? If we didn't, then why the database system doesn't provoke an error telling us that the column doesn't exist in the first place? Is this the normal way a database behaves?)

Ben, PortSwigger Agent | Last updated: Mar 08, 2022 09:16AM UTC

Hi, At this stage, you are trying to identify columns that can hold string data (rather than trying to identify database table names) so that you can eventually retrieve interesting data from your attack. If the data type of a column is not compatible with string data then you will receive an error, if it is compatible then no error should occur. You can then use this information to build your attack (effectively, what the labs are doing in this section are trying to teach you how to approach this systematically by finding out how many columns are required in a UNION attack, which columns can hold string data etc).

DOCTOZip | Last updated: Mar 08, 2022 08:32PM UTC

Dear Mr. Ben, Thank you for taking time to respond to my question. I would like to explain my point further, because I think you didn't get me well. I clearly understand that this section is trying to teach me how to find out the number of columns required in a UNION attack. However, the problem I am facing is beyond the section's approach. When the web application receives my browser's request, then converting it to SQL queries, noted for example as: SELECT column1, column2, column3 UNION SELECT 'a', NULL, NULL--, the database system will compare automatically the number of columns of both queries, if validated, then it will compare the datatype; let's assume the datatype is the same in both queries, but after this point immediately, the database system should return an error (this is only a suggestion, I have no idea how db system works), because when it will start processing the queries after the two conditions has been validated, the db system will try to SELECT a column called ('a') which doesn't exist. I am asking if the db system should return an error because this column doesn't exist in the first place (if it exists how did we know?), or it will be just ignored without provoking any actions just like it did with the NULL column.

Ben, PortSwigger Agent | Last updated: Mar 09, 2022 08:28AM UTC

Hi, I think you may have misunderstood my last post. You are not checking the names of database columns at this point in time, you are checking what data each column in the original query can hold (the 'a' could be anything - 'abc', 'portswigger' it does not matter etc - it is merely used to check the data type of the column). So, in a hypothetical scenario where two columns are being used, the following payload would check whether the two columns could hold string data (if they are compatible you should not receive an error, if they cannot hold string data then you will receive an error): '+UNION+SELECT+'abc','def'-- The following payload would specifically try and obtain information from the 'username' and 'password' columns in the 'users' table (please note the difference in how this query is constructed): '+UNION+SELECT+username,+password+FROM+users--

DOCTOZip | Last updated: Mar 10, 2022 06:26PM UTC