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."
Related
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
I am trying to determine if there are any good methods for scanning a website database to determine if the site has been compromised. I am reviewing a Drupal website which may have been exposed to an SQL injection vulnerability.
I understand that hackers will often hide code in the database using hexadecimal literals to avoid filters.
I am wondering if there was any method or tool one could use to scan a database for suspicious content?
If your database is changing constantly.. then it is very difficult to know if your database is exploited (involves cyber forensics).
Also, many of the SQL injection attacks involve gathering information than modifying.
There are tools for checking the vulnerabilities of a site. You can use them to patch the vulnerabilities instead.
You can use the following tools for this purpose:
SQLNinja
SQLMap
Source: Automated SQL injection Detection
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
I'm making a web service with Django that uses MySQL database. Clients interface with our database through URLs, handled by Django. Right now I'm trying to create a behavior that automatically does some checking/logging whenever a certain table is modified, which naturally means MySQL triggers. However I can also do this in Django, in the request handler that does the table modification. I don't think Django has trigger support yet, so I'm not sure which is better, doing through Django code or MySQL trigger.
Anybody with knowledge on the performance of these options care to shed some light? Thanks in advance!
There are a lot of ways to solve the problem you've described:
Application Logic
View-specific logic -- If the behavior is specific to a single view, then put the changes in the view.
Model-specific logic -- If the behavior is specific to a single model, then override the save() method for the model.
Middleware Logic -- If the behavior relates to multiple models OR needs to wrapped around an existing application, you can use Django's pre-save/post-save signals to add additional behaviors without changing the application itself.
Database Stored Procedures -- Normally a possibility, but Django's ORM doesn't use them. Not portable across databases.
Database Triggers -- Not portable from one database to another (or even one version of a database to the next), but allow you to control shared behavior across multiple (possibly non-Django) applications.
Personally, I prefer using either overriding the save() method, or using a Django signal. Using view-specific logic can catch you out on large applications with multiple views of the same model(s).
What you're describing sounds like "change data capture" to me.
I think the trade-offs might go like this:
Django pros: Middle tier code can be shared by multiple apps; portable if database changes
Django cons: Logically not part of the business transaction
MySQL pros: Natural to do it in a database
MySQL cons: Triggers are very database-specific; if you change vendors you have to rewrite
This might be helpful.
I am working on a business app (asp.net). Right now I am using sql server. But I plan to support at least mysql and postgresql down the road.
What are the issues that I should consider to avoid future headaches? Especially about datatypes (column types). E.g. I think BIT column is not supported on some dbs so I use tinyint?
I mostly use plain sql (no entity framework or linq, etc) and try to keep it as simple as I can.
I am NOT using things like triggers, etc.
I do use stored procedures but they can be replaced with plain sql if I have to.
Your only hope is to separate data access into a proper data access layer, as Remus Rusanu suggests. The data access layer can have one consistent interface to the rest of your code, and be changed out for other versions for each DB platform. Keeping the SQL fairly standard will help, but it's not really possible to write one body of SQL code and have it work everywhere (the SQL standard isn't that well implemented.)
Consider (with some costs in term of learning curve) the adoption of a Domain Model and a data access layer based on an OR/M like NHibernate (https://www.hibernate.org/343.html)
Make sure you write all your client code using the abstract IDbConnection, IDbCommand, IDataReader instead of the concrete. You will also have to keep your SQL statements in check all the time to ensure you use only compatible syntax.
You can also try connecting via the OdbcConnection/OdbcCommand components and use generic ODBC syntax and generic ODBC data types (ie. the {fn SUBSTRING(...)} stuff, aka. the ODBC Escaped Syntax).
As an alternative what I prefer to do is to isolate the data access and create specific DAL classes for each back end. I use XML and XSLT to generate the DAL code. Similar to this the technique of integrating XSLT code generation from my blog, but with XSLTs geared specifically for each back-end specific code.