Viewed   63 times

I'm developing a website and I'm trying to secure the connection part.

I used the addslashes function on $login to stop SQL injection but some friends told me that's not enough security. However, they didn't show me how to exploit this vulnerability.

How can I / could you break this code? How can I secure it?

<?php

    if ( isset($_POST) && (!empty($_POST['login'])) && (!empty($_POST['password'])) )
    {
        extract($_POST);
        $sql = "SELECT pseudo, sex, city, pwd FROM auth WHERE pseudo = '".addslashes($login)."'";
        $req = mysql_query($sql) or die('Erreur SQL');
        if (mysql_num_rows($req) > 0)
        {
            $data = mysql_fetch_assoc($req);
            if ($password == $data['pwd'])
            {
                $loginOK = true;
            }
        }
    }
    ?>

 Answers

5

You should use mysql_real_escape_string for escaping string input parameters in a query. Use type casting to sanitize numeric parameters and whitelisting to sanitize identifiers.

In the referenced PHP page, there is an example of a sql injection in a login form.

A better solution would be to use prepared statements, you can do this by using PDO or mysqli.

Sunday, October 2, 2022
 
mr.m
 
1

SQL injection attacks happen when user input is improperly encoded. Typically, the user input is some data the user sends with her query, i.e. values in the $_GET, $_POST, $_COOKIE, $_REQUEST, or $_SERVER arrays. However, user input can also come from a variety of other sources, like sockets, remote websites, files, etc.. Therefore, you should really treat everything but constants (like 'foobar') as user input.

In the code you posted, mysql_real_escape_string is used to encode(=escape) user inputs. The code is therefore correct, i.e. does not allow any SQL injection attacks.

Note that it's very easy to forget the call to mysql_real_escape_string - and one time is enough for a skilled attacker! Therefore, you may want to use the modern PDO with prepared statements instead of adodb.

Tuesday, September 27, 2022
1

SQL Injection and XSS are the most common mistakes that programmers make. The good news is that they are easiest to automatically test for, as long as you have the right software. When I am on a pentest I use Sitewatch or Wapiti for finding web application vulnerabilities. Acunetix is over priced.

But, you can't just fire off some automated tool and expect everything to work. There are a number of precautions you must take with ANY vulnerability scanner you choose.

1) make sure display_errors=On in your php.ini Sql Injection tests rely on being able to see mysql error messages in the response pages! No error, no vulnerability detected!

2) Scan the authenticated areas of your application. Create a user account specifically for testing. Acuentix has an easy wizard where you can create a login sequence. If you are using wapiti you can give a cookie to wapiti or give wapiti a post request to fire off but this is kind of tricky.

AFTER you have tested your application then test your server for misconfiguration. To test your server then you need to run OpenVAS which is the new more free version of Nessus which is now a commercial product. Then you should follow this up with PhpSecInfo. These tests will notify you of problems with your configuration or if you are running old vulnerable software.

Nothing will ever be 100% secure, EVER. No matter what you do there are vulnerabilities that will slip though the cracks. There are vulnerabilities in all development platforms that lead a compromises that no tool can test for. There are also bugs in the testing tools you use. There are false posties and false negatives and some tests that just don't work, a good example i have never seen an automated CSRF tool that actually finds legit vulnerabilities. Acunetix's CSRF test is a complete waste of time.

There is also the OWASP testing guide which goes into greater detail. This is not to be confused with the OWASP Top 10 which is also an excellent resource. The PHP Security Guide is also a great resource for php programmers.

Monday, October 24, 2022
 
4

First of all, it's just bad practice. Input validation is always necessary, but it's also always iffy.
Worse yet, blacklist validation is always problematic, it's much better to explicitly and strictly define what values/formats you accept. Admittedly, this is not always possible - but to some extent it must always be done.
Some research papers on the subject:

  • http://www.imperva.com/docs/WP_SQL_Injection_Protection_LK.pdf
  • http://www.it-docs.net/ddata/4954.pdf (Disclosure, this last one was mine ;) )
  • https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf (based on the previous paper, which is no longer available)

Point is, any blacklist you do (and too-permissive whitelists) can be bypassed. The last link to my paper shows situations where even quote escaping can be bypassed.

Even if these situations do not apply to you, it's still a bad idea. Moreover, unless your app is trivially small, you're going to have to deal with maintenance, and maybe a certain amount of governance: how do you ensure that its done right, everywhere all the time?

The proper way to do it:

  • Whitelist validation: type, length, format or accepted values
  • If you want to blacklist, go right ahead. Quote escaping is good, but within context of the other mitigations.
  • Use Command and Parameter objects, to preparse and validate
  • Call parameterized queries only.
  • Better yet, use Stored Procedures exclusively.
  • Avoid using dynamic SQL, and dont use string concatenation to build queries.
  • If using SPs, you can also limit permissions in the database to executing the needed SPs only, and not access tables directly.
  • you can also easily verify that the entire codebase only accesses the DB through SPs...
Friday, November 18, 2022
4

No, ES6 template literals are just another way to build strings and don't protect you against SQL injections if you were to use them to build raw SQL queries from supplied user input without additional filtering / escaping:

let name = "Robert'; DROP TABLE Students;--"; // user supplied input

let sql = `SELECT * FROM Students WHERE name = '${name}'`; // build query...

console.log(sql); // Injected SQL!
Sunday, August 7, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :