Is there any way to confirm that a particular breach of security was done through SQL injection?
There is no easy way here, but if you have the enabled the SQL server you use to log every single sql statement, here is what I would do.
Normally, when I SQL inject somewhere, i use one of these as my always true statement for passing throgh the Where clause, after ending the former string.
1=1
0=0
both being used as :
blahblahblah' or 1=1 --
You would not use this clauses in everyday code. So if you spot one of these in your history, well, it is a high candidate. Test the sql history to find :
(space)(number)(optional spaces)(equal)(optional spaces)(same number)(space)
Keep in mind that is heuristical, and will not always work, but could be the only way to give a hint after it had happened . Also, if you are in doubt about SQL injection, you should check the code for string concatenation and use of parameters.
after the attack has already happened? no. there isn't.
you'll have to check all your sql serevr access point for potential risk.
tere are some tools you can use. Check here under SQL Injection tools section.
SQL injection can happen any time you pass a query back to the database.
SQL Injection
Use mod_security to log POST requests and install an Intrusion Detection System to log/stop suspicious activity from now on. Logging every SQL request is an overhead if you are just looking for the breach points.
There are open source alternatives for IDS these days. I use PHPIDS for all my PHP applications.
Only one reliable way is probably analysing the SQL log files. Those should be done by a DBA who can spot things quickly as the size of logs would be huge.
It is better to prevent those.
There are some tools for that but the best one is the brain of the developer.
Stick with one simple rule - always use parameters when generating SQL query.
Just do the code review and if you find string cocatenations - that is first and highly possible place for SQL Injection.
You can log all http requests and check the requested pages for GET/POST sql injection tryouts.
Related
I have an application in which I'd like to accept a user supplied SQL query from a front-end query builder (http://querybuilder.js.org/). That query eventually needs to make it's way to running in a postgres database to return a subset of data.
The query builder linked above can export SQL or a mongo query. I imagine using the mongo query is relatively safe, since I can add to it simply on the server:
query.owner_of_document = userId
to limit results (to documents owned by the user).
Whereas the SQL statement could potentially be hijacked in an injection attack if someone attempts to store a malicious string of SQL for execution.
Is directly accepting SQL from a client bad practice? How can I ensure the supplied SQL is safe?
Thanks!
Why do you need to accept an entire SQL statement?
Can you accept only parameters and then run a pre defined query?
There are loads of questions/answers on SO relating to SQL injection and using parameters is a first step in avoiding injection attacks, such as "Are Parameters really enough to prevent Sql injections?"
But I think this answer to a different question sums things up well:
Don't try to do security yourself. Use whatever trusted, industry
standard library there is available for what you're trying to do,
rather than trying to do it yourself. Whatever assumptions you make
about security, might be incorrect. As secure as your own approach may
look ... there's a risk you're overlooking something and do you
really want to take that chance when it comes to security?
Im designing a UWP app that uses an SQLite database to store its information. From previous research I have blearnt that using the SQLite function SQLiteConnection.Update() and SQLiteConnetion.Insert() functions are safe to use as the inputs are sanitised before entering in the database.
The next step I need to do is sync that data with an online database - in this case SQL Server - using a service layer as my go between. Given that the data was previously sanitised by the SQLite database insert, do I still need to parameterise the object values using the service layer before they are passed to my SQL Server database?
The simple assumption says yes because, despite them being sanitised by the SQLite input, they are technically still raw strings that could have an effect on the main database if not parameterised when sending them there.
Should I just simply employ the idea of "If in doubt, parameterise" ?
I would say that you should always use SQL parameters. There are a few reasons why you should do so:
Security.
Performance. If you use parameters the reuse of execution plans could increase. For details see this article.
Reliability. It is always easier to make a mistake if you build SQL commands by concatenating strings.
Perhaps it may sound strange but I was told that SQL injection attacks
can be classified as:
passive and active
Passive SQLi:
it is related to SQL statement such:
SELECT,UNION,GROUP BY,LOAD,HAVING EXECUTE, BEGIN, DECLARE...etc
Active SQLi:
it is supposed to be more dangerous since it involves modifying the DBMS through statements like: UPDATE,DELETE,INSERT ..etc so
I haven't yet found anything about it in terms of white papers, study material and so on.
OWASP defines passive and active sql injections here
SQL Injection is classified in the following two categories, depending
on the exposure of database information (passive) or the alteration of
database information (active).
Both are problematic, and if you have one you probably have the other. The problem with active is fairly obvious (someone is updating/creating/deleting your data in ways you didn't plan). Passive is just as dangerous though for you and your users though. Imagine if they get a list of usernames and passwords. These could be used to login legitamently to your website, or to other websites as most users reuse passwords on multiple sites.
SQL injection is simply adding undesired text to your queries.
You can group it as you wish, but it doesn't really matter, the simple thing is, your query doesn't do what you want or does not only what you want.
I've never heard of sql injection attacks being broken down into categories. As gdoron so eloquently put it, it doesn't matter.
However, looking at how you broke it down it almost makes sense. I'd change that classification slightly to be:
Passive:
Attack involving overriding the expected input in such a way as to bypass normal security controls. For example, let's say you have a page with a query string such as:
/accounts/edit.php?id=50
In this case, manually changing the id to 1 or 10 could potentially pull up a record the user does not have access to. Provided that the edit page doesn't perform additional checks to ensure the user has access.
Active:
Attack whereby sql statements are passed into input fields in order to cause the application to execute the new statement.
For example, putting ' or (1=1);drop table users;' into a login field. Some applications simply concatenate sql with unsanitized user input. This could allow an attacker to bypass security controls or even send DDL statements to the database server.
I wouldn't say that SQL injection involving DELETE is necessarily "worse" than SQL injection involving SELECT. It's true one can modify data and the other doesn't.
But a lot of scary SQL injection is perpetrated solely to read data that is supposed to be restricted, e.g. stealing credit card numbers.
Usually the terminology around SQL injection has to do with the methods of attack, such as "blind SQL injection," "union-based SQL injection," etc.
If you want to read a mighty book that covers the subject very well, try SQL Injection Attacks and Defense by Justin Clarke et. al.
Because SQL Injection is a technique used to ATTACK a website, wether it is passive or active is of inconsequence as many of the others members have said already.
No the TERMS you use in the first paragraph are PASSIVE is incorrect,
Execute is not passive, its active... its Executing (something or other)
And even a passive term such as SELECT when used with DropTable can cause you to lose data too!
So you would still insist on calling it passive?
When its ACTIVELY dropping a table?
A good source of further information is wikipedia.
http://en.wikipedia.org/wiki/SQL_injection
It seems that one could stop all threat of Sql injection once and for all by simply rejecting all queries that don't use named parameters. Any way to configure Sql server to do that? Or else any way to enforce that at the application level by inspecting each query without writing an entire SQL parser? Thanks.
Remove the grants for a role to be able to SELECT/UPDATE/INSERT/DELETE against the table(s) involved
Grant EXECUTE on the role for stored procedures/functions/etc
Associate the role to database user(s) you want to secure
It won't stop an account that also has the ability to GRANT access, but it will stop the users associated to the role (assuming no other grants on a per user basis) from being able to execute queries outside of the stored procedure/functions/etc that exist.
There are only a couple ways to do this. OMG Ponies has the best answer: don't allow direct sql statements against your database and instead leverage the tools and security sql server can provide.
An alternative way would be to add an additional tier which all queries would have to go through. In short you'd pass all queries (SOA architecture) to a new app which would evaluate the query for passing on to sql server. I've seen exactly one company do this in reaction to sql injection issues their site had.
Of course, this is a horrible way of doing things because SQL injection is only one potential problem.
Beyond SQL Injection, you also have issues of what happens when the site itself is cracked. Once you can write a new page to a web server it becomes trivial to pass any query you want to the associated database server. This would easily bypass any code level thing you could put in place. And it would allow the attacker to just write select * from ... or truncate table ... Heck, an internal person could potentially just directly connect to the sql server using the sites credentials and run any query they wanted.
The point is, if you leverage the security built into sql server to prevent direct table access then you can control through stored procedures the full range of actions availble to anyone attempting to connect to the server.
And how do you want to check for that? Queries sometimes have constant values that would just as easy be added to the query. For instance, I have a database that is prepared to be multi lingual, but not all code is, so my query looks like this:
SELECT NAME FROM SOMETABLE WHERE ID = :ID AND LANGUAGEID = 1
The ID is a parameter, but the language id isn't. Should this query be blocked?
You ask to block queries that don't use named parameters. That can be easily enforced. Just block any query that doesn't specify any parameters. You can do this in your application layer. But it will be hard to block queries like the one above, where one value is a parameter and the other one isn't. You'll need to parse that query to detect it, and it will be hard too.
I don't think sql server has any built in features to do this.
I'm trying to log hibernate activity (only dml operations) to an sql script file.
My goal is to have a way to reconstruct the database from a given starting point to the current state by executing the generated script.
I can get the sql queries from log4j logs but they have more information than the raw sql queries and i would need to parse them and extract only the helpful statements.
So i'm looking for a programatic way, maybe by listening the persist/merge/delete operations and accessing the hibernate-generated sql statements.
I don't like to reinvent the wheel so, if anybody know a way for doing this i would appreciate it very much.
Thanks in advance
Generally the best way to do this is to just turn on logging on your SQL server. All the major RDBMSes support logging all the SQL statements that they run. This has the added advantage of catching things that happened outside of Hibernate.
You could also try to use NHProf which will intercept/record hibernate traffic to the database and dump it into an XML file. You might have to parse the file by hand, but all the information will be there.
You could also hook at the JDBC level directly and record the JDBC statements that are performed.
P6Spy is a great tool to inspect what's going on. It can log the queries, though I don't know if you can replay them as is.
I'm sure there are other such tool (or at worse you could try subclass the DataSource, Connection and PreparedStatement implementation of your choice to do that yourself).