Skip to main content

Privilege Escalation with Like Query

Continuing with my last post "DoS with Like Query", another impact of it I want to discuss here. As I had said that the % and _ qualifier is often overlooked by developers to filter as its not so devastating as other characters. They are used for matching zero or more characters and single character respectively. I got a taste of it again when I was assessing an application recently.

The application had several roles. Role A can't access data of Role B (that's obvious :) ). The Authorization checks were properly implemented-so no chance of Privilege Escalation.

When I was examining the application closely, it has various search modules based on several conditions. If you search for a record after filling up a long form with fields with name, location, unit, suggestion no., suggestion name..blah,blah,blah. The one thing I noticed that the application was using the 'Supplier Name' field to search the records and listing down only those records which has matching name of the 'Supplier Name'. One more thing, the application was free from 'standard' SQL Injection. From 'standard' I mean, the application was not vulnerable to single quotes, double quotes or any other SQL related queries. But again the same mistake- it was not filtering % in the fields.
The 'Supplier Name' was going like a hidden field. If nothing matches, the response page was throwing a message:
No suggestions found.
Supplier Name: % John D'souza%

Now it was more than enough to suggest that the application is running Like query for searching the records "WHERE supplier_name Like {hidden_supplier_name}%'".

Here the % does the trick. Replace the hidden_supplier_name with % and the application was displaying not only records (suggestion nos) of the respective logged in supplier, but also it liste down contents of whole database. Needless to say that it contained data of other supplier's also.
Moreover if the database has millions of records, it can create DoS also.

You can treat it as a form of SQL injection also as you are exploiting the LIKE query SQL statement. So beware of % also. ;)

Comments

Post a Comment

Popular posts from this blog

File Upload through Null Byte Injection

Sometimes, during file upload we come across situation wherein there would be check on the file extension at the client side as well as server side too. If the application does allow only .jpeg extension to be uploaded, the client side java script checks for the extension of the file before passing the request. We all know that how easily this can be defeated. Some applications, checks for the extension at the server side also. That's not easy to bypass. However there are some ways with which it still can be bypassed. Most of server side scripts are written in high level languages such as Php, Java etc who still use some C/C++ libraries to read the file name and contents. That leads to the problem. In C/C++ a line ends with /00 or which is called Null Byte. So whenever the interpreter sees a null byte at the end of the a string, it stops reading thinking it has reached at the end of the string. This can be used for the bypass. It works for many servers, specially php servers. T...
1 comment
Read more

'Information Leakage-Improper Error Handling' dropped

From Owasp Top 10 2010 List, the issue 'Information Leakage-Improper Error Handling' has been dropped. But it's not the final list,its child release actually. Bu I feel it shouldn't be set aside because its still the one of the prevalent issues these days. That's why I mailed to Dave Wicher: Hi Dave, Excellent work, Congrats! Just one little query- Don't you think that Information Leakage & Improper Error Handling still deserves to be in Top 10? Dave replied: This topic is clearly a very prevalent issue that deserves attention by most organizations. However, the typical impact of such a flaw is usually very low. Therefore, the overall risk of this type of flaw is lower than the other items in the top 10, which is why it was replaced in this update with one of the 2 new items. Regarding dropping Info Leak/Error handling - It is incredibly prevalent, no question. But their impact is typically very low, so the overall risk is low, which is why it fell out of t...
3 comments
Read more

Breaking Excel password protection

If you came across an excel sheet asking for password for allowing to make any changes into it, you may want to unprotect it. All we need to do is to edit the xml file which comes intrinsically packaged with Excel 2007 or 2010. But what about Excel 2003? For that, open the Excel 2003 file within Excel 2007, save it as xlsx file. So, keep in mind all the Excel files below 2007 version, you need to convert them as Excel 2007 with extension .xlsx. Now here are the steps for doing that: 1. Open the Excel 2003 file (e.g. Secret.xlsx) and save it as .xlsx (Excel 2007) format. If you already have Excel 2007 file, then no need for any conversion. 2. Now change the extension of the above file to .zip and extract the zipped file. Browse through the file in the extracted folder and go to: <LocalPath>\Secret\xl\worksheets.   3. Now open the sheet/ sheets you want to remove protection in any xml editor. Look for keywords such as 'sheetProtection' or 'workbo...
10 comments
Read more