April 2, 2019 at 4:50 pm
We had a SQL Injection attack recently on our website. Looks like it came through a "Contact Us" PHP form.
I'm not a PHP developer, and wondering who/what is a good resource to look at the PHP code to see what the vulnerabilities are. It's about 500 lines, and handles the usual contact us type info, writing to a SQL database.
April 2, 2019 at 5:24 pm
What was the nature of the SQL injection, and how did you discover it happened?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 2, 2019 at 5:52 pm
A scheduled job had 0 results, and we found a table had all the records deleted.
I then used my trace file logging and found the injected SQL code deleting the records.
I would like to understand how the PHP code allowed it to get in.
April 2, 2019 at 7:06 pm
I would change the page to use a a stored procedure to do whatever the page is doing. Passing in data to be inserted, updated or deleted using variables will prevent injection by separating SOL command from the data to be processed,
April 2, 2019 at 7:38 pm
My guess is, if the injection attack was through the Contact Us page, is that you have non-parametrised statements in your PHP. There are 2 easy, but possibly very time consuming (depending how bad your code is) steps you need to perform: parametrise <span style="text-decoration: underline;">every</span> SQL statement on your website and ensure the login/user your website is using has the minimal permissions it needs. Code like (recalling my PHP very poorly) the below is BAD!
$sql = "INSERT INTO dbo.ContactUs (Email, Reason, Details) VALUES ('" & $Email & "','" & $Reason & "','" & $Details & "');"Is bad!!! Someone could easily inject into that by putting the in something like the following for $Details: '); SELECT * FROM sys.databases; --.
There are plenty of guides, and documentation, on how to parametrise PHP; I suggest having a read and taking that website offline until you fix all the problems.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
April 2, 2019 at 7:43 pm
I would change the page to use a a stored procedure to do whatever the page is doing. Passing in data to be inserted, updated or deleted using variables will prevent injection by separating SOL command from the data to be processed,
Using an SP alone won't fix the issue. If the OP is using non-parametrised statements in PHP, then using an SP won't fix that. Along with the example in my above reply, the below is <span style="text-decoration: underline;">just</span> as bad:
$sql = "EXEC ContactUsInsert '" & $Email & "','" & $Reason & "','" & $Details & "';"
Parametrising the PHP is the only solution here. Of course, you could change the login/user that the website uses to only have EXEC permissions, but that would still allow someone trying to inject into the query; if the statements aren't sanitised.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
April 2, 2019 at 8:09 pm
Looks like we have some "Bad" code.
Thoughts ??
$sql = "update MyTable set Username=".$memNum." where memNum=".$memNum;
$results = mssql_query($sql, $dbconn);
.
There's some other using SP writing to WordPress:
$stmt = mssql_init('usp_MySQL_Insert',$dbconn);
mssql_bind($stmt, '@MemNum', $memNum, SQLINT4, false, false, 10);
mssql_bind($stmt, '@Password', $password, SQLVARCHAR, false, false, 64);
$result = mssql_execute($stmt);
mssql_free_statement($stmt);
April 2, 2019 at 8:21 pm
Yes, that first statement is wide open to injection. The second, however, looks to be parametrised (it's been about 10 years since I used PHP, so I'm awfully rusty). You need to fix every instance where you aren't using a parametrised statement; that is going to likely be a long task but is the reason why you server was injected into.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
April 2, 2019 at 8:23 pm
Thanks. This particular page only seems to have a few instances that need to be modified.
But there are probably other pages on the website that are vulnerable.
April 2, 2019 at 8:25 pm
If a stored procedure isn't an option, then another safe guard would be to grant the mssql account used by the Contact page to have only insert permission on this table. Any attempts to exploit the page to delete from or select from the table would result in an error. Also, any error messages coming from SQL Server should not be displayed back to the website, only a general error 500 page.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 2, 2019 at 8:28 pm
If a stored procedure isn't an option, then another safe guard would be to grant the mssql account used by the Contact page to have only insert permission on this table. Any attempts to exploit the page to delete from or select from the table would result in an error. Also, any error messages coming from SQL Server should not be displayed back to the website, only a general error 500 page.
How do you prevent SQL error messages from displaying ?
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply