Are additional measures to prevent SQL injection attacks really necessary?

Asked

Viewed 130 times

0

I was taking a look at some projects on the internet that involve security and came across the following code.

All requests to the site were redirected to index.php for mod_rewrite, the connection to the database was made with PDO, using Prepared statements, everything was in the pattern, however I went to take a look at the index and I came across this code

    /** O projeto permite somente slugs com 250 caracteres **/
    if (isset($_GET['params']) && (strlen($_GET['params'])  > 250)) 
    {
        header('HTTP/1.0 403 Forbidden');
        die('<b>O endereço atual excede os limites de segurança</b>');
    }

I thought it was very strange and I decided to go down to check.

I used the sqlmap to do some tests and the same did not get results. I took this line that I posted above and did the tests again, basically it didn’t change at all except in the Apache logs that I could see that the sqlmap strings were "passing", instead of being "Barradas" by the script and generating 403 errors.

To secure the application and save server resources, the code above is a preventive or unnecessary measure?

php security-guard
  • 2

    I think the word "security" in this case is being used in a figurative sense (i.e. a very large Slug could cause bugs in other parts of the application for whatever reasons). and not in the literal sense. But it’s just a hunch...

  • There’s nothing in what you posted that reinforces security with respect to SQL Injection. The script only prevents the application from proceeding if Slug is more than 250 characters long and triggers a security warning if it occurs. As already mentioned, it is an exaggeration because it is not about safety, but about business rules and also because the GET method is limited to 255 characters. In short, it is a very coarse gambiarra. Applied confusingly by firing a 403 Forbidden with message about safety.

  • It’s confusing to give an answer. If you can change the question to something more relevant, at least relevant to the title or modify the title according to the text, I think it might become feasible

1 answer

4


I don’t quite understand the question, it seems to me that you say that $_GET['params'] is passed to mysql, it does not seem to avoid sqlinjection, I believe there may be two reasons:

Friendly URL (Slug)

Reading about the term "Slug" it means that urls should be easier for human reading, i.e., we are talking about rewritten urls (mod_rewrite), an example would be:

  • Title of page/article: How to create friendly urls!

  • Name string for url: how-to-create-friendly urls

    In the code used this Slug has a limit of 250 characters, because the idea is that if it is larger it will probably be difficult to be "remembered" by the user. Not that the proposed solution will solve, but it is a way to try to avoid the problem.

Avoid connections to mysql without need

Think like this, if the parameters are invalid there is no need to connect in mysql, this would save a little the server, because apparently there are no urls with more than 250 characters, because every time you make a valid request it connects to the mysql server, I know it would be difficult to have multiple connections with invalid querys.

About the code you quoted I noticed a strange thing because it seems to try to avoid strings larger than 250 (strlen($_GET['params']) > 250), but as @rray said, strlen returns bytes and not characters, so maybe the code doesn’t work as well as expected.

  • 1

    I think the question code is concerned with treating Undefined index, remember that the strlen() returns the number of bytes and not characters.

  • From what I understood of this code it counts the number of characters that I put in the URL, because if I put more than 250 it gives that message that is inside the die(); I found very strange this code, the idea seems to be good to spare the server, but I did not understand the code itself.

  • Unless you want to send a hash as a parameter, or the parameters are "unknown", That check is a waste of line, and it has nothing to do with protection. I personally did not understand the reason, there are much better ways to deal with problems like this as already mentioned.

  • Doing some tests it seems that the only thing he did was to spare the BD from invalid queries, nothing more, I think that really the word security was used wrong there.

  • I’m researching these things because I will do a TCC with the theme of security next year, I will not invade anyone not hehe, thanks for the answers.

  • 1

    @Renancavalieri would not say wrong, but rather the interpretation of it, he may believe it is the safety of the user remember :) - But really it is better to avoid the use of the word in this context.

Show 1 more comment

Browser other questions tagged php security-guard

You are not signed in. Login or sign up in order to post.