SQL injection: why can?t we learn?
Recently we have been all witnesses of two high profile incidents where the attackers exploited SQL injection vulnerabilities: the now infamous HBGary Federal hack and the Barracuda Networks hack. What’s even more worrying about these two incidents is that they happened to companies which are information security consultants/product developers.
SQL injection vulnerabilities have really been around for ages – the first reference I can remember of was Rain Forest Puppy’s article for Phrack 54 “NT Web Technology Vulnerabilities” that was published back in 1998 (yes – SQL injection is almost 13 years old!). However, as we can see from the examples that happened recently (and from many other cases – just take a look at the mass SQL injection attacks that are performed automatically by malware these days) SQL injection vulnerabilities are unfortunately here to stay.
During my penetration testing engagements I often see various frameworks that are being used to develop web applications. These frameworks are really more and more advanced these days and can in many cases automatically protect the application against common attacks such as SQL Injection or Cross Site Scripting.
While this is good and frameworks definitely help make applications more secure (note that I didn’t say secure), one thing that I always like to stress out to developers that they should still pay attention to all these vulnerabilities. If nothing else, you never know if your application will end up on a server that will have a different or misconfigured version of the framework you used which will suddenly make your application vulnerable!
Another thing to keep in mind is that web application firewalls aren’t almighty. While they can do a good job, I’ve also seen too many misconfigured WAF products that were easy to bypass. The web technology is developing quickly and if you don’t keep up with it, it is quite possible that in 6 months a new attack/language/whatever will be introduced that will allow one to bypass your (old) WAF. Take Adobe Flash for example – not only for client side vulnerabilities – but also for attacks such as Cross Site Flashing that are more and more common.
So are the bad guys any better? Unfortunately, the answer is YES. When I get my hands on, I always try to analyze server side scripts that the bad guys use – these are usually scripts running on their C&C servers that help them control infected machine, issue and schedule tasks and so on.
While previously we were seeing all kinds of bad code (both bad looking and full of vulnerabilities), today I can unfortunately say that the bad guys have much improved their game. Below you can see an excerpt of a server side script used by some malware. It’s in PHP (the most popular platform for bad guys) and besides being nice and easy to read, notice how they nicely used the addslashes() call on all variables to make sure that any occurrence of a single quote, double quote, backslash and NULL byte characters is properly escaped.
So, if the bad guys can do it, we should be better to – so please use couple of minutes to educate your developers about the dangers of writing insecure code.
--
Bojan
INFIGO IS
Comments
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
https://defineprogramming.com/
Dec 26th 2022
8 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
8 months ago
rthrth
Jan 2nd 2023
8 months ago