I recently had to investigate an SQL incursion and noticed how -- is a great help for an attacker. Considering it's not a very useful instrument in many web environments, but seems to add to the damage potential of such vulnerabilities, why not disable it? I couldn't find a way, hence the question.
It is not possible to disable SQL comment parsing.
The correct solution is to ensure your application does not allow it to occur by always escaping user input, or better yet by using parametrised queries of some kind whether directly through the MySQL server API or through a user library that does it client-side.
Disabling comments may help a little, but it is very easy to do SQL injection without them, they can simply write the start of another complete query instead of commenting out the remainder of the statement.
If that is not practical for some reason, you may be able to consider the MySQL Enterprise Firewall (this is a commercial product and not open source) which allows you to setup a query whitelist:
https://www.mysql.com/products/enterprise/firewall.html
Related
I am developing a client-side only web application for learning purpose, using WebSQL to store and query data, and Javascript to process it. WebSQL is not mantained anymore, but the question may be valid for all client side databases.
In the proposed specification for WebSQL from the W3C, §8.5 recommends a specific syntax (parameterized queries using ? as placeholder for values) to avoid SQL injection attacks.
Given that the user is free to modify the Javascript code used in the web page, including SQL statements (or alter the database using the development Console or other browser tools) why should the program be prepared to avoid SQL injections?
I found three StackOverflow questions related to SQL injection in WebSQL, this one, this one and this answer but none of them highlights why SQL injection is a concern on client side databases.
May someone else has a clear motivation, why SQL injection is a concern on client side databases?
SQL injection makes sense when considering unwanted third party operations on the database.
A client-side web application involves:
the developer, who designs the database and SQL statements;
the user, who can modify them using browser tools;
third-party scripts, such as libraries, which cannot access the application database.
Actually, databases are specific to one origin, so that a script cannot open a database belonging to an other origin:
If no database with the given name from the origin origin exists, then create the database
(§4.1 of the WebSQL W3C specification)
A third party attack script may use the DOM of the page to fill in form inputs with attack code, which will be injected when the form is submitted (possibly by the attacker itself, calling the submit() method of the form element). To avoid this, use parameterized queries: user input will never be interpreted as SQL code.
I would say that "an SQL injection attack" is distinct from a "I'm gonna modify the program, or better yet, just write my own" attack.
Yes, you are entirely correct in observing that a user can do anything he wants to, to a database and to software source-code that winds up on his computer. But, this is not an "SQL injection."
"SQL injection," I think, represents any case where an outsider effectively modifies the database structure or content from the outside, and without directly modifying the source-code or supplying new source-code of his own.
It could well be argued, as essentially you just did, that SQL injection is much less likely to occur with regard to a database that exists only on the client computer. I think that your argument is sustained. But, I don't think that this is a successful argument for abandoning the use of parameters. I flatly recommend that one should never insert literal, externally-provided values into any SQL string, "period."
I'm seeing a weird url repeatedly in my logs and I'm wondering if someone is able to understand what this user was attempting to do. I'm a little familiar with the basics of MySQL, however, I'm lost with this one (especially the 0x7e parts), and want to prevent future possible vulnerabilities. I've found and am correcting the vulnerability in my script, however I'd really like to know what this person was doing. Any insight you can offer would be greatly appreciated. Thank you.
Note: I replaced my actual database and table names below with DatabaseName.TableName to make it clearer.
Here's the weird url:
photo.php?member_id=11616%27+AND+(SELECT+7509+FROM(SELECT+COUNT(*),CONCAT(0x7e,0x7e,0x7e,0x27,(SELECT+CONCAT(MID((IFNULL(CAST(member_id+AS+CHAR),0x20)),1,50),0x3A,MID((IFNULL(CAST(email_address+AS+CHAR),0x20)),1,50),0x3A,MID((IFNULL(CAST(password+AS+CHAR),0x20)),1,50))+FROM+DatabaseName.TableName+ORDER+BY+member_id+LIMIT+81947,1),0x27,0x7e,FLOOR(RAND(0)*2))x+FROM+INFORMATION_SCHEMA.CHARACTER_SETS+GROUP+BY+x)a)+AND+%27FtCw%27=%27FtCw&name=1392855.jpg
I believe so. They're testing to see if you are susceptible to SQL injection.
The INFORMATION_SCHEMA.CHARACTER_SETS table is tested because all users have read privilege to this table regardless of what privileges you otherwise give them. I can't imagine the attacker is really interested in how many character sets you have, so they're probably just seeing if they can get that query to run. If they confirm this, it means that they can proceed to use other attacks.
You need to block that attacker's IP address ASAP. Then review your code to make sure you are safe from SQL injection vulnerabilities.
well i have been through penetration testing and testing these kind of attacks.. this query is generated by SQLMap a penetration testing tool (written on python) to check if the link is vulnerable to Sql Injection or Not.. bt make sure if its only testing mean u r conducting this urself.. if he managed to access ur database he can compromise the server even..
u can check more on sql map here..
Project Sql Map
A normal UNION based SQL Injection can be blocked using the WAF, which filter keywords like UNION, SELECT. But I've that it can be bypassed by the inline comment statements of SQL such as /*!UNION*/ and /*!SELECT*/
Comment statements are meant for only reading purpose, right? If so, how a SQL server reads the injection query inside the comments and executes it?
Filtering keywords with a WAF is pointless. There is no way it could possibly succeed. Take a look at this list of ways to bypass it: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/ (And I found that link in just a few seconds with google.)
If the code was written correctly, it would not be necessary.
As for your question the /*! syntax of MySQL is for MySQL specific commands. It's intended for you to be able to write portable SQL (that can run on any database) and yet still be able to send MySQL special commands.
SQL injection should not be an issue at all if you're using a database driver that supports placeholders for data. What you'd be trying to do with an after-the-fact detection is futile, like trying to eradicate a roach infestation with a ratty fly-swatter. You can't possibly get them all.
The best practice is to ensure it's impossible to inject hostile data into your queries in the first place. There are many examples available on Booby Tables that illustrate how to do this properly.
Commenting out partial query by not closing them can be used for bypassing blacklisting, removing spaces, obfuscating and determining database versions.
The one that you've mentioned is a special comment syntax for MySQL. If you put a code into this comments it's going to execute in MySQL only. Also you can use this to execute some code only if the server is higher than supplied version. For example:
Classical Inline Comment SQL Injection Attack Samples
ID: /*!32302 10*/
ID: 10
You will get the same response if MySQL version is higher than 3.23.02
Some background:
We provide a complex system consisting of a large database and several programs - most written in C#, however some legacy applications are still running on MFC.
Most of the stuff we provide runs on a single server (runs SQL server and SQL Management studio 2005), however several applications can run on a number of client's computers. Updating this is a real pain, since after we update the database the outdated software is likely to break due to database changes. Updating the server software manually is one thing, however making sure all the client software works too is practically impossible, and will only get worse with time.
I am to write an updating service, which will be able to update the whole product - update the database, reinstall services and applications. (However only the programs / files /tables / etc that are actually modified should be updated. Downloading the whole product each time there is a update available is not an option. Also, some computers may only have a subset of avaliable programs installed)
First of all is there a already a good way of doing this? If there is something similar to ClickOnce that would also be able to update databases already out there I'd much rather use that.
If not, what are the best practices when it comes to updating? All and any material will be greatly appreciated.
I will need some updates to be installed on the server ASAP after the updates have been submitted, without any user input. That includes a windows service (that is running at all times) and any database changes. After these changes have been made, I will have to prevent any software that is not up to date from either accessing the parts that have been changed, or from running at all.
Any advice will be greatly appreciated - If I do have to write a system like that, I'd like to do it right.
Best practice would be to package the app up in an MSI and use Group Policy to push the updates out to each client.
If that's not possible then you need some way of informing the client app that it is out-of-date (simple check against a server holding the current version number would probably suffice) and refuse to work until an update patch is downloaded and installed - you could even launch this process from inside the app itself.
This answer may help you, I haven't personally used Wix but this seems to be along the lines of what you're looking for. Make sure to check out Lesson 4 in the linked tutorial, as this provides the details you would require.
I'm not sure where you would find best practices when it comes to updating, but in my personal opinion you shouldn't ever force a user to update unless it breaks the underlying application (like yours does). I would be very interested to hear if someone has a link to a list of best practices on this topic.
Edit
I was interested in possible best practices for updating so I started another question thread here. The general consensus in the answers is "Ask the user/client", but there may be some other details in the answers which may help you, I'm afraid I can't find any actual hard rules on the subject anywhere (which I was expecting).
Long story short, we found files promoting prescription drugs on our server that we didn't put there. The Windows server has very old applications and runs MySQL 5.1.11.
Beyond other security flaws, could SQL injection be used to write files to the server file system? I am certain that some of these old applications are vulnerable to SQL injection attacks. I would NOT think that this is possible, but I seem to remember reading somewhere that MySQL could access the "command line" and write files via it though I can not locate a source for that info. Then again, my mind could be playing tricks on me.
If this is possible, is there a setting that can disable it?
Also, I'm not looking for the answer that says get rid of the SQL injection vulnerability. While that obviously needs to be done; I'm looking for a quick short term fix that will prevent the rogue files from magically appearing again while the SQL injection vulnerabilities are being fixed. Fixing all the old applications is going to take lots of time.
Thanks.
It's possible, especially with suitably careless configuration.
For example, there is SELECT ... INTO OUTFILE 'file_name'
But it's also more likely to be a different security problem. I'd seriously consider taking the software offline quickly, especially if the database contains any confidential or private information
as Colin Pickard shows, yes.
but even if you can't update your application, i doubt it needs the rights it's currently running with. you need to check the user it logs in to mysql with and trip those permissions down to the minimum. specifically in this case, you should remove the FILE privilege if your app does not read/write files stored on the mysql server.
Setting the permissions of the application directory to read-only for the web account might work. This assumes that you're not already creating files in it like logfiles and such.