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