Through PHPDeveloper I came across a Devshed article related to SQL Injection.
The one major flaw in the article is that it is suggested input validation is enough protection. This is not the case. Lets start with this example ...
In this article we will discuss security for databases accessed through the Internet. We will also examine the issue of password management, since handling that task properly will help us make our web site and its applications more secure. This is the seventh part of an eight-part series that shows you how to build security into an application for an Internet cafe.
MySQL and SQL Column Truncation Vulnerabilities
August 18th, 2008 | by Stefan Esser |
While SQL-Injection is one of the most discussed security problems in web applications other possible problems for SQL queries like overlong input are usually ignored although they can lead to all kinds of security problems.
This might be caused by the fact that security problems that are the result of overlong input are often buffer overflows and buffer overflows are something many web application security experts know nothing about and choose to ignore.
There are however several security problems for SQL queries that are caused by overlong input and no one talks about.
Top Ten Security Vulnerabilities in PHP Code ...
Escaping user-input in your HTML is essential for preventing worlds #1 vulnerability.
When you're embedding user input into javascript, a simple htmlspecialchars won't cut it, you'll need to make sure you're escaping other things, like n (line endings), and (slashes). Google doctype has a good list of characters in need of proper escaping to prevent users breaking your javascript.
However, when I dropped the question if a simple string replacement would be good enough, the members of the Web security mailing list gave me a different answer.
When escaping or filtering output using a blacklist (such as the one published on google doctype) browser/unicode escaping bugs are not taking into consideration. Some new vulnerability might appear in the future, which would immediately open a hole in your app. For this reason its wiser to go with a much more defensive white-list approach, essentially only letting things through you know is safe.
Reform is a tool that does exactly this. Reform allows you to escape your data for a javascript, xml, html or vbscript (yes it still exists) context. It provides libraries for Java, .NET, PHP, Perl, Python, Javascript and ASP. Pretty cool!
Mit Suhosin existiert eine PHP-Erweiterung, die es erlaubt, bestehende PHP-Anwendungen mit einfachen Handgriffen und oftmals ohne Änderungen im Quellcode gegen bekannte und unbekannte Angriffe abzuhärten. In diesem Artikel soll die Installation und Konfiguration beschrieben und der sichere Einsatz der Erweiterung demonstriert werden.
Developers place too much trust in everything, they assume that certain data cannot be faked and therefore these pieces of data can be used as a Trojan horse. Lets take the REMOTE IP of a user, it seems a trusted source because of the TCP/IP connection between the user and the server but take the following example ...
The session was a bit different from the usual talks I give on security, focusing on summarizing the efforts done so far this year aimed at improving PHP's own security and the things we are still working on improving.
If you have a system where users can subscribe and choose there own passwords, you are probably a target for brute force attacks like a dictionary attack. You can limit this problem by showing user how strong their password is. However forcing users to enter a really strong password will annoy them, since they like something they can remember.
Another way wall you can put up is blocking an IP address for a few minutes upon a number of login failures. This is not a waterproof protection, but the hacker now requires a botnet to perform the brute force attack. To rent a botnet is quite expensive and to create one is quite difficult, so your average script kiddie doesn’t have one of those. So based on the data you’re protecting this should be a decent defense.
Setting up this defense isn’t difficult. I’ll show an example how to do this with APC.
Alexander Andonov (Mordred) has written an articled called The Unexpected SQL Injection for the Web Application Security Consortium:
We will look at several scenarios under which SQL injection may occur, even though mysql_real_escape_string() has been used.
The focus of the article is stressing the importance of filtering input and escaping output, as neither is a substitute for the other, but he does so very clearly with specific examples that include queries that use integer values (sans quotes), user-supplied column names, LIMIT clauses, and LIKE clauses. A number of example exploits are supplied for each case, and he discusses which ones work, which ones don't, and why. It's a good article and worth a few minutes of your time.
