What is an example of an SQL injection attack for compromising the database?
What classes of SQL injection attacks cannot be prevented by the use of bind variables and why not?
How do bind variables help in preventing SQL injection attacks?
http://xkcd.com/327/
Speaking of native prepared statements - all the query literals which aren't supported (i.e. everything but simple strings and numbers) are obviously vulnerable, when not hardcoded.
https://stackoverflow.com/a/8265319/285587
1.:
Here's an example from the real world:
https://find-and-update.company-information.service.gov.uk/company/10542519
Since the company is still listed the attack seems to be unsuccessful as yet, however, in the case the injection succeeds in the future, I'll also include a screenshot.
Related
I'm learning about SQL Injection. And sometime I read in some document that we have to use unhex(hex()) function when exploit in URL address.
And my question is, why we have to use it?
First off, it cannot help you with SQL injection. If SQL injection is impossible, then no hex/unhex/whatever function will make it possible.
It can only help to exploit an existing SQL injection, when a site is protected by a very silly protection method like a black list disallowing a single quote in the input. So these functions can help to avoid using a quote or any other "malicious word" that may alert the filter.
But honestly, I cannot imagine a developer in 2018 using a black list filterig against SQL injection instead of prepared statements for the data/a white list for the everything else
I am using Server.HttpEncode(), and HttpDecode() in order to sanitize user form input, as well as having the server throw an exception when a "potentially dangerous" input is detected.
(Data is then saved to an MSSQL database)
Is this considered enough to stop SQL / Javascript injection and similar?
No it doesn't prevent it at all. It is used more so to prevent XSS attacks as explained by Microsoft here. Read this Stackoverflow question for some ideas on preventing SQL injection.
Depending on the environment you are in, I would use a technology such as the Entity Framework or NHibernate which prevents SQL injection altogether, so you do not even have to worry about it.
Possibly, but almost certainly not.
So I know that Rails helps protect against sql injections when used like this:
Object.find(:first, :conditions=>["name=?",name])
However, I can't seem to find if the autogenerated find_by and find_all_by methods protect agains sql injection.
i.e:
Object.find_by_name(name)
So these two calls have the exact same result. My question is even though the second one is more convenient, should I continue to use the first because it provides protection against sql injection, or does the second do that as well?
Yes, dynamic attribute-based finders (find_by_* family) do protect your app from sql injections.
Typically I use integer ids in my application, but for this one piece of dev I am doing look ups on a text field - a tag name.
I do make use of cfqueryparam but considering that it's a text field, could it be vulnerable to sql injection attacks, and if so, how do other people get around this other than tediously searching the string for SQL commands.
My query looks something like:
SELECT tagId -- etc etc
FROM tag
WHERE tagName = <cfqueryparam cfsqltype="cf_sql_varchar" maxlength="50" value="#arguments.tagName#" />
Thanks
That's safe by virtue of the fact that you're using <cfqueryparam>. That's what the tag does. It sends the value as text (or whatever the cfsqltype happens to be), not a command to be executed.
For the most part yes... doing sql injection for this would be very difficult. CFQUERYPARAM does make it almost impossible to sql inject a query. However, remember that nothing is 100% effective against all forms of attacks.
If you did not use cfqueryparam, then you would be vulnerable.
By using cfqueryparam you don't need to worry about SQL injection.
Try putting in injection attacks and see for yourself.
I've heard somewhere that using cfqueryparam together with Portcullis would be a stronger protection against XSS and block malicious hack attempts.
Most ColdFusion web developers are now finally using cfqueryparam, it
has taken about 10 years since that tag was introduced but I guess
better late than never. Keep in mind, that cfqueryparam prevents most
forms of SQL injection but not all. It also does nothing to cross-site
scripting (XSS) attacks. It doesn't matter how small your site is or
where it's hosted, it will experience these attack vectors. Portcullis
takes maybe 5 minutes to install and configure. Nothing is perfect,
but Portcullis has a solid track record - just google it. So, there's
simply no reason I can think of where a ColdFusion based site
shouldn't use it.
http://www.codfusion.com/blog/post.cfm/portcullis-2-0-released
Also, you may want to watch CFMeetup: Warning, your site is under attack presented by John Mason, the author of Portcullis.
When using ORM's (Entity Framework, LINQ to SQL, NHibernate ...), are SQL injection attacks mitigated by design?
If not, where should I be doing some extra validation/scrubbing to prevent a vulnerability?
Most, if not all, mainstream ORMs use parametrized SQL, which will protect you from a direct SQL injection attack. However parametrized SQL at the application layer will not protect you from latent SQL injection attacks. These occur when something down the line, other than the ORM, directly concatenates user input in a SQL statement (such as a batch run stored procedure that concatenates user input to create a non-parametrized dynamic query). Note that this isn't an ORM issue at all, but I thought I'd bring it up to point out that parametrized SQL only protects you from injections if it is used everywhere, not just in the ORM.
They are in NHibernate by using parameterized queries.
ORMs are designed to be secure, in the basic concepts. Most of the time you'll not have to worry about it, but if you think you might be exposed to real cracking you should do some custom tunning.
For simple apps, simple SQL injection you'll be cover. No body (seriously, no body ever) will give you a silver bullet in matters of security and SQL Injection. That's my advice.
ORMs typically use a lot of dynamic SQL, which is insecure because it gives users of the application and/or service accounts the ability to execute ad-hoc SQL queries. The correct solution is for only Programmers and DB Admins to have DataReader/DataWriter and all programs that touch the database to use nothing except parameterized Stored Procedures always with no DataReader/DataWriter access associated with the program. They can only access the SPs I say they can. Only the DB Admins and Programmers should be able execute ad-hoc SQL queries.