In the industry that's a fair point it's called ethical hacking, there's a certain reason as to why allot of people in companies that do this for part of a larger penetration testing, usually amounting to a few £1,000's worth of expenditure, it's not cheap! Hence why not allot of people give out information on such a niche market for income.
(Original post by ch0llima)
You shouldn't be doing that unless it's part of a legitimate penetration test.
But SQL Injections only a very very very small part of a penetration testing.
There is a suite of utils you can pay for, but it's not meant for commerical use if not paid for, called Nessus I think it is, I use it at work for the projects within the company but obviously on a licence and free at hom for my own example project work.
Companies like Sysnet are the companies that do professional penetration testing (or Pen test as it's best called since it just sounds dirty if you say the full word lol).
All SQL injection actually is, is being able to say you where the developer at a company and they have not updated your SQL to prevent SQL injection and you did this on purpose, you wanted to get a list of all the companies suppliers and their all on this web accessible website you made, so what do you do?
Use certain syntax in the query text boxes to select * (* being the name for all fields) from the suppliers database, gaining access to information the query you setup should prevent against using things like inverted comma's (') or SELECT statements with syntax to be able to gain access to this information, when you send in commands to an SQL server though, like mysql_real_escape_string in PHP if you have an entry for a blog say 'My User's'< double inverted comma's after mysql_real_escape_string() has been used it would come out with the following: 'My User\'s' escaping the first character but on a larger scale it sends in the details of your query as pure text not a command so any DROP or DELETE commands simply would turn out to be SELECT statements so SELECT DELETE tablename wouldn't work lol.
That's how you prevent against SQL injection in PHP, there's other ones available to other languages I suppose though.
Or just use is_numeric if it's user entered data, or else why would you be doing SQL injection prevention methods?
(Original post by NutterFrutter)
mysql_real_escape_string to secure strings.
abs and intval will suffice to secure numbered inputs.
(Assuming the language is PHP.)
If it's meant to be a whole number for example I would cast the variable to an integer, then check the casted integer against the original value of the users entry, if they don't match throw back an error or assume what the user has put (I tend to stay away from that), there's a good example on my blog which I need to finish off soonish lol.
Last edited by j.smith1981; 05-09-2011 at 14:27.
Interesting statistics, but ultimately not a very good indicator of vulnerability.
(Original post by estel)
Sadly, there are a lot of terrible developers out there, and security is massively massively hard: even some of the best developers will have significant security vulnerabilities in their software.
In the Web Application Hacker's Handbook, the authors discuss their research into "hundreds" of web applications conducted 2006-2007 (so still somewhat out of date, but not irrelevantly so). They found vulnerabilities in the following proportions (of all sites):
If you can provide more recent figures, I'd be interested in hearing them.
As an example, if you were being anal about security your username/password form should have the same message for an invalid username as an invalid password. Does that count as broken authentication? It probably does count as information leakage. But so is storing usernames and passwords in a publicly accessible text file on the server. One is somewhat more serious than the other.
I'd be more interested in what the vulnerabilities allowed you to do, instead of giving the type of vulnerability (although there is a correlation...).
Last edited by Chrosson; 09-09-2011 at 01:32.