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.
Related
Actually I am working in a web application that interacts with some other systems, but there is no actually a DB system, for some reason it was designed in that form, the topic here is that somebody tried to execute some security scan and with the tool Arachni performed some Blind NoSql and Blind SQL injection, according to this person, the system is vulnerable to this kind of attacks based on the scanner tool, but my question is.
There is a real risk of something if there is no exist database? an attacker can have some other privilege using this kind of attack?
SQL injection attacks only work with databases. If your system can't provide an anwser to an SQL query you don't have to worry at all about this.
I have no idea what kind of web aplication you have developed (you didn't give any information) but, even if you have an actual database, the sql injection code must works, and that's impossible with no database.
I was looking at the logs and found a sql injection. Looks like it is used alot but I don't really understand how it works. I attempted to submit it through the form they submitted it through but nothing happens.
The injection string is:
(select(0)from(select(sleep(0)))v)/*''+(select(0)from(select(sleep(0)))v)+''"+(select(0)from(select(sleep(0)))v)+"*/
Can't figure out how they injected it. Didn't affect the server from what I can tell. They didn't get any data. But I still want to know how they made it work.
This is a vulnerability check. It's one of the easiest and safest way to figure out if your server is vulnerable to SQL injection - and more importantly, it doesn't need any attention from the would-be attacker! You can use a method like this to test sites automatically for SQL injection vulnerabilities - and in this case, it means that the potential attacker can run any kind of query or command, you seem to have no checks whatsoever. Needless to say, this is bad.
You should consider your server compromised - it's probably on someone's list now, pending further exploitation. Fix the issue ASAP, and ideally prevent the functionality altogether right away if the real fix is going to take some time.
The idea behind this is that a vulnerable server will respond differently to a query with different values for the sleep argument - this means that it's very easy to automatically go through all possible inputs (don't forget that even things like hidden fields and dropdowns can be changed at will) and find out if any of those are vulnerable. When this works, you can either inject a malicious query/command outright, or keep using the sleep to figure out information directly - particularly useful when there's no data you could make appear to the outside by modifying the vulnerable query. By series of yes-no questions (based on simple if(whatever, sleep(5), 0)) you can determine enough to press your attack further.
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.
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.
This may seem like an obvious (or not so obvious) question, but let me explain. I'm coding up a Google App Engine site using Google's database technology, BigTable. Any App Engine coders will know that Google has its own limited query language called GQL. As a result, I am tempted not to do any checking for SQL (or GQL) injection in my app since I assume Google is not using a raw string query on its backend methods to fetch data.
Furthermore, libraries for DB technologies like CouchDB, MongoDB, and other object or document (aka NoSQL) databases seem to obviate the need to check if a malicious user is injecting database manipulation commands. They often have libraries that directly map the objects in the database to object in your language of choice. I know there are many SQL libraries that do this as well, but I assume that at some level they are combining parameters to run a query over a string, and thusly I must still use SQL Injection protection even with those frameworks.
Am I being short-sighted? Or is it only a matter of time till the next great DB system takes hold and then I will see injection into those systems?
“Injection” holes are to do with text context mismatches. Every time you put a text string into another context of string you need to do encoding to fit the changed context. It seems seductively simple to blindly stuff strings together, but the difficulty of string processing is deceptive.
Databases with a purely object-based interface are immune to injection vulnerabilities, just like parameterised queries are in SQL. There is nothing an attacker can put in his string to break out of the string literal context in which you've put him.
But GQL specifically is not one of these. It's a string query language, and if you go concatenating untrusted unescaped material into a query like "WHERE title='%s'" % title, you're just as vulnerable as you were with full-on SQL. Maybe the limited capabilities of GQL make it more difficult to exploit that to completely compromise the application, but certainly not impossible in general, and in the very best case your application is still wrong and will fall over when people try to legitimately use apostrophes.
GQL has a parameter binding interface. Use it. Resist the allure of string hacking.
SQL-subsets like GQL obviously still concern themselves with it -- but pure non-SQL databases like CouchDB, Voldemort, etc should put & get data without concern for SQL-injection-style attacks.
That however does not excuse you from doing content validation, because while it might not break the database, it may break your application and allow things like XSS (if it is a web app).
Anytime data that is from or manipulated by user input is used to control the execution of code, there needs to be sanitization. I've seen cases where code used user input to execute a command without sanitizing the input. It hadn't been exploited, but if it had been it would have been a horrible attack vector.
SQl Injection is only a subset of a type of security flaw in which any uncontrolled input gets evaluated.
techincally, you could "inject" javascript, among others.