150 ways to let hackers in
Shut that (code) door
Cloud storage: Lower cost and increase uptime
To paraphrase Paul Simon, there are 150 ways to leave your software open to attack, according to Fortify Software, the Palo Alto-based security software specialist.
In the latest update to its Fortify Security Coding Rulepack, the company says it has added a further 34 "vulnerability categories", bringing the grand total to 150.
Fortify's philosophy is that the best place to deal with security threats is in source code when software is being built. Well-designed code can prevent a wide range of attacks and Fortify's Source Code Analysis tool helps improve code design and keep out the malcontents.
"Security threats are a constant challenge to programmers - but their priorities are to meet deadlines and deliver new features. We can help by giving them good tools to help make software less vulnerable," says Jacob West, manager of the security research group at Fortify.
According to Fortify, the two most-prevalent forms of attack are cross-site scripting, where rogue code pretends to be from a trusted site, and SQL injection, where executable SQL commands are put into data streams.
West says cross-site scripting can be prevented by using data flow analysis. "You can identify data as it comes in and check that it is what it says it is. A billing address, for example, should only contain letters and numbers. If it contains special characters then it may well be suspect."
Similarly, SQL injection may be avoided by ensuring that SQL data streams do not contain executable instructions. "SQL injection introduces extra commands into an SQL stream which can circumvent access control and enable data to be changed. If you can control the SQL command input you can do almost anything. But you can prevent it by input validation and restricting what you allow in commands."
The rulepacks are part of Fortify's Manager Security Control Centre. ®
COMMENTS
Some simple tricks
As a web developer and IT manager, part of my job is ensuring that the websites we develop are protected against these sort of attacks. I generally have a few simple fallbacks that, while not guaranteed to prevent an attack (nothing CAN be truly hackerproof short of not having it connected to any network), still make it harder to compromise the site.
First, all my Perl scripts check specfically for HTML delineators in input strings (greater-than/less-than signs), and erase them. I'm sure The Reg does something similar as HTML does not work in these comments either.
Second, I use regexes to search for SQL in input strings, such as:
if ($input{$key} =~ /(select|alter table|insert|delete).*(from|where|values)/i){doEraseSQL();}
Third, I ensure that my code never uses a direct input string in a database access command. Input strings only ever represent data to be placed in the database, not access commands.
There are many other ways, too numerous or complex to elucidate here, but these tricks show that just a little extra forethought and coding can save a lot of trouble and money later on. It doesn't have to be hard, you just have to consider the possibilities and allow for them in your code.
West[ward]'s Response's
I think you might just be advertising a golf course, but you do raise an interesting point: It can be very difficult and restrictive to identify an appropriate whitelist for security.
It's this inherent difficulty that makes programs that use strong whitelists more secure. By causing developers to explicitly select the characters that should be accepted, the technology forces some thought into accepting input, which can otherwise be a somewhat haphazard process.
Once you think about exactly which characters you should accept, you're much more likely to identify the characters that could be dangerous. Then you can proactively decide what to do about them, which might mean rejecting the input outright, or might encoding the data so that the special characters no longer have their dangerous meaning.
Exception to the rule
"You can identify data as it comes in and check that it is what it says it is. A billing address, for example, should only contain letters and numbers. If it contains special characters then it may well be suspect."
What happens if your billing address is Westward Ho!
http://www.devonlink.co.uk/smtowns/westward-ho.php
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
