Sign in / up

back to article 150 ways to let hackers in

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 …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. amanfromMars

    Achilles heel

    Cross Site Scripting and SQL postings are impossible and definitely self-defeating to prevent if the Code that they inject is Intelligently Designed to Create further Mutual Benefit rather than attack the System which has warranted ITs attention. It is a quite natural reaction to invite further attention to explore the cracking Good Code. Some systems though are closed because of the narrow, selfish agendas that they serve and that quite rightly causes them a dilemma as cracking Good Code will not bother them and wait for their acceptance of it, but rather pass them by and offer itself to a rival System. And it is the Third Party, Positive Reinforcement of IT that gives it its controlling strength. It also identifies corrupted systems fearful of better Code working for Mutual Benefit/Open Source. In Politic terms, it is Chronic, Dark Matter Capitalism against Sunny, Hail Fellow Well Met Socialism..... the Pervert against the Lover.

    0 0
  2. Anonymous Coward
    Anonymous Coward

    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

    0 0
  3. Jacob West

    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.

    0 0
  4. Steve Roper

    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.

    0 0
This topic is closed for new posts.