0

First of all, let's get one thing straight, while im sure it's not the ONLY solution to sql injections, PREPARED STATEMENTS ARE BETTER and MORE SECURE... that's granted.

So let's not debate it anymore, as I just needed to explore the escaping options and target the user inputs rather than the statement..

(a bit of back story) I have a huge application w/ lots of basic SQL statements which i need to make "safer" in a short period of time. Converting all statements to PDO is a monster of a task which requires resources not available to this situation.

But good thing is that there's a hook in the application where ALL incoming $_GET/$_POST passes through a function before making available as plain variable in the scripts... ( eg.globalize($_POST) )

So i'm looking to target that function instead and focus on "cleaning" user input ...

I pretty much got a good grasp of SQL injection techniques, and basically much of its concept, such as: 1) Whenever there is user input involved in a statement, that's when the attacker has an opportunity 2) The main mission is to break your statement's quoting by simple single or double quotes as string, or character codes, in the attacker's input.. 3) Escaping is good at preventing SQL injections except for that situation when the DATABASE character encoding is able to ready multibyte representations of those nasty illegal strings and the script based escaping misses it.

Based on the above premise, what if:

1) All my SQL Statements follow a standard where user input is quoted using single quotes ALWAYS, therefore there is no guess work for me anymore on what type of quote i need to escape (single quotes)

2) all user inputs (POST / GET) go through a function (eg. globalize() ) that basically addslashes() and globalizes each variable

3) This is an intranet application and the scripts can be made aware of the database encoding support.

QUESTION: What are the threats currently available in the above situation and how can we handle them?

...i personally was looking into simply adding routines to the globalize() function similar to mysql_real_escape_string() .. or go as far as "tweaking" the SQL statements to use mysql_real_escape_string() as that is a lot easier/faster to do than programming statements on each sql query..

PS Of course this script may never be as secure as prepared statements, but i just need to make it hard enough for most attackers (not looking to 100% bullet proof it as it is not that worth it)

BrownChiLD
  • 3,545
  • 9
  • 43
  • 61
  • 5
    You should use `mysql_real_escape_string` rather than `addslashes`, since it's specific to the database. Other than that, if you can't convert to prepared statements then what you're doing is as good as you can get. – Barmar Aug 19 '14 at 01:46
  • You already got the core issues correct, in particular the `1)` type-irrespective quoting. So if you really want to go through that unwieldy extraneous effort, I'll allow it. However, why should we redebate SQL syntax and injection issues here for the umptbillionth time? Why not show the actual code you want to evaluate? – mario Aug 19 '14 at 01:49
  • @barmar thanks .. at least I know i'm doing best i can in this situation.. – BrownChiLD Aug 19 '14 at 01:53
  • if globalize is doing something like extract($_REQUEST) you are in trouble – Daniel Williams Aug 19 '14 at 02:02
  • @DanielWilliams - well it's basically a simple $varname = addslashes($_POST['varname']); so it's pretty controlled and i can tap into this function.. – BrownChiLD Aug 19 '14 at 03:24
  • Watch out for cases where the user is expected to input a numeric value, and this value is passed to a SQL statement. mysql_real_escape_string won't help you in this case, nor will adslashes. See http://www.iodigitalsec.com/mysql_real_escape_string-wont-magically-solve-your-sql-injection-problems/ for a good example of how you can get burned in this type of case. – mti2935 Aug 19 '14 at 10:34

2 Answers2

0

Using

mysql_real_escape_string($link,$non_escaped_string);

See here: http://php.net/manual/en/mysqli.real-escape-string.php

user3105700
  • 365
  • 5
  • 16
0

While it might well work, there are a few possible issues.

If you use addslashes then there are potential exploits, hence for MySQL mysql_real_escape_string() is generally better. There is a potential flaw in mysql_real_escape_string() (which also applies to the default use of pdo), but this is so esoteric you pretty much have to try to make your code open to an attack based on it.

The bigger issue is that your user input could possibly be used on different databases with different character sets. Hence you should specify the link to the database that the escaped string will be used in. If you do not specify this the the details of the last link opened will be used. If no link has already been used then it will try and connect itself with some default connection parameters and the results are likely to be unpredictable.

If you just escape all the $_POST / $_GET / $_REQUEST arrays (and remember that $_COOKIES array is also subject to being changed by a mischievous user) then the likely place you would do this would be when the scripts are first loaded, when you are unlikely to have connected to the appropriate database.

A further issue is that some of the code you are dealing with (and which you seem not to have the time deal with in detail) is bound to already escape the input data. Hence you will land up double escaping it with strange results. Related (but less likely to be an issue) is escaping numeric fields

Kickstart
  • 21,403
  • 2
  • 21
  • 33