Assuming you are authorized to pentest a live website that's login page is vulnerable to SQL Injection.

Lets say your backpack has only 2 crafted queries by you which is admin' -- and '=' 'OR'.

Your past experience on a test site where its back-end SQL code is as simple as belows

select * from users where username = '$username' and password = '$pass';

Yes! This 2 admin' -- and '=' 'OR' cheat-sheet in your backpack works for bypassing for the above SQL statement.

Okay! Now! Here comes the real live website for you to pentest. But only this '=' 'OR' cheat-sheet in your backpack works instead of this admin' --

So best guess is this live website you are authorized to pentest on is having a different back-end SQL code implementation than the one I stated above and only is able to be bypassed by 1 crafted cheat-sheet in your backpack which is '=' 'OR' and not admin' --

My question now is how do you picture this back-end SQL query code? Assuming you do not have access to the back-end code at all!

How do you make a report out of this? Saying this cheat-sheet '=' 'OR' works but what about the back-end code that is vulnerable to it? Since you do not know how the back-end code is implemented that is vulnerable and you can't come up with a migitation or prevention approach report for it?

  • 6
    We investigate. Pen-testing is not about script-kidding by cheat sheets. It's all about intelligent investigation. – Your Common Sense Jun 3 '19 at 15:42
  • How much do you know of about the SQ language? Start there. – DarkMatter Jun 3 '19 at 15:43
  • Hmm looks like you guys are not answering my question. To prevent a long comment here. Please kindly skip to the last part for a summary instead. – Cash- Jun 3 '19 at 15:44
  • I am trying to scope/clarify the question – DarkMatter Jun 3 '19 at 15:48
  • 2
    Looks like for some reason you are asking the same question over and over again – Your Common Sense Jun 4 '19 at 9:41

I believe the following contrived back end would satisfy your requirement:

SELECT * FROM Customers Where '$uid'='SuperUser'

Which becomes

SELECT * FROM Customers Where ''=''OR''='SuperUser'

As for preventing this sort of thing the answer is true for all SQLI. Sanitize and validate all user inputs.

  • 1
    JFYI, "Sanitize and validate all user inputs" is not clear, and even being the source of many injections. All terms here are unclear and ambiguous. What is "sanitize"? Will escaping HTML entities be enough? How does "validate" actually help? Is a static HTML form element a user input? A data from your own database, already validated? – Your Common Sense Jun 4 '19 at 7:37
  • @YourCommonSense True but the "how to prevent injection" question has been asked and answered time and time again...It is a simple search away. My answer is obviously focused on the specific question present here. – DarkMatter Jun 4 '19 at 13:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.