3

I found a way of inserting an SQL injection through a non-secure query. The program is a checkpoint control that works with QR codes. It checks if your code exists in a database and if it does you are welcome to enter the facility.

Now... as that is the only input from non-staff people, measures against SQL injections are not being taken in the code. Now if I take an "infected" QR code to input to the system I am sure it will make them believe the threat... how would you exploit this? (SQLite)

"SELECT count(*) FROM validation WHERE qrstring='" + qrcodestring + "'"

I found a couple but nothing major like getting valid codes from other users or something like that...

Also, is my fear logical, or is this safe? Because, I was made fun at for exposing this.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
wannabeLearner
  • 180
  • 1
  • 10
  • 1
    How is the output presented? if you want to get information out of the system (as opposed to just fool it to log you in), it needs to display the result of the query somehow. – Anders Sep 01 '16 at 09:49
  • 3
    What you discovered is a legit vulnerability (if it works), and nothing to make fun of. The fact that they did is still not a reason to do something illegal. Just saying. – Anders Sep 01 '16 at 09:51
  • 1
    @Anders it is not illegal. I was the creator of the system, it was just not ready for distribution but you know how companies are... i just want them to update it and to do so i must prove there is a issue with it. I am showing in a textbox if the card is valid or not but if you can fool it to accept it it would work. – wannabeLearner Sep 01 '16 at 10:15
  • 2
    Possible duplicate of [How to extract information using a SQL injection on PHP?](http://security.stackexchange.com/questions/135077/how-to-extract-information-using-a-sql-injection-on-php). The first answer only answers the title question, not the actual question, but the other answer should answer your question (you can still extract information, even if you don't show anything) – tim Sep 01 '16 at 11:51
  • @tim going to link it in the answer as i thing is solves some of the issues i presented and is an amazing answer, actually pined it to read later. – wannabeLearner Sep 01 '16 at 13:38

2 Answers2

2

I've found out the answer I was looking for, although there is no way (that i know of) of displaying other codes because I don't present the database information in anyway. still it is possible to bypass the security verification by using a simple ' or ''='. My solution for this was adding complexity layers to the type of codes my program accepts, for example, I am using a GUID and I know it has 36 chars on length 3 hashes (-)... and a code that does not present this characteristics is not allowed to interact with the database at all.

Check this awesome answers for more on-topic information.

Community
  • 1
wannabeLearner
  • 180
  • 1
  • 10
  • *"it has 36 chars"*: be sure to check what these chars actually are (ie. genuine hexadecimal chars) to correctly reject strings like `00000000-0000-0000-0000-000' or ''='` which also counts 36 chars with the expected dashes. – WhiteWinterWolf Sep 01 '16 at 13:19
  • @WhiteWinterWolf true well spotted will make a verification for that as well. – wannabeLearner Sep 01 '16 at 13:49
  • 1
    @wannabeLearner Additional input validation is a very good habit and should definitely happen as defense in depth, but as WhiteWinterWolf has shown, it is not enough in a lot of situations. Prepared statements are really the only acceptable solution to sql injection. You should never directly insert variables into queries (doesn't matter if it's in some backend, you may also not want all your staff to have complete control over your database; if not now, maybe in the future). – tim Sep 01 '16 at 13:58
1

Also, is my fear logical, or is this safe?

This is not safe. Information can be extracted, for example via blind injection.

And your fear is logical. There is no good reason to not have defenses against SQL Injection.

On the pro side you have:

  • not all staff people should always have complete control of your database. Maybe this isn't the case right now, but it may be in the future.
  • User input may still reach the application if there are other vulnerabilities. CSRF would be one of the more likely ones, but if this is accessibly from the outside, authentication problems may cause issues as well.
  • Your requirements may change. Maybe some of the input that is currently staff-controlled needs to be user-controlled. Now what? You need to change the existing code, and hope that you don't forget some places.
  • if your code leaks, this may lead to damage to the companies reputation, as it is generally accepted that unsecure coding is not acceptable.
  • in this case, the input actually is user controlled. This is nothing to make fun of, this may very well be a very serious security issue.

And there are no cons. Prepared statements are easy to write, and result in better, easier to read and easier to maintain code.

I originally votes to close as duplicate, but after re-reading your question decided to answer anyways, as the question doesn't only seem to be about how to exploit this, but also if defenses against sql injection are needed at all

tim
  • 29,018
  • 7
  • 95
  • 119
  • This is exactly what i was looking for, and as i can see there are a lot of vulnerabilities, that is why i want to update it, but i am going to rewrite it with all the things i learned in mind. Thanks! – wannabeLearner Sep 01 '16 at 14:16