back to article Time to dismount the hamster security wheel of pain

Enterprises are spending a huge amount of effort scanning for vulnerabilities that they already know are in their applications. Here's a little secret: there's no point in scanning if you haven't at least tried to put in a basic set of defenses. You already know you're vulnerable. So what kinds of defenses does the average web …

COMMENTS

This topic is closed for new posts.
  1. Lou Gosselin

    Security problems caused by clueless programmers

    There isn't always much we can do unless security is a project in and of itself. Every faulty line of code needs to be fixed and regression tested. I have even had a client ask me to revert back to vulnerable code since their client's depended on it. I can hear it: "That's a feature not a bug".

    Some of the most notorious attacks such as cross site scripting and SQL injection attacks are trivial to fix: convert all data strings into the encoding used by the medium. This shouldn't be more than a few lines in any modern language, and that's only if the escape/encode functions are not already defined by the language.

    Problem is, amateur programmers tend to make the same mistake hundreds of times, and by the time they're discovered, the damage is done and the product is already in production.

    And then when it's time to fix the vulnerabilities, users go about solving it the wrong way. Like rejecting the data (via regex or other means) in lieu of proper encoding of the fields. Even Asp.Net pages display a server error when it sees a less than sign. Why *can't* I use "<" in a text box? And Why *can't* I use an apostrophe in that name field? Many names have an apostrophe. Should we do away with these keys on the keyboard since developers don't have a clue how to handle them properly?

    The problem is, employers just think about cheap labor and not so much about quality when choosing among candidates. Until that changes, the vulnerabilities will remain common.

  2. Mark Fenton
    Dead Vulture

    The English in this article is appalling

    Two easy examples - missing word "that" in "Most people recognize **that** developers should not build their own encryption mechanisms"

    And, I think you mean "you're" not "your" in "Now your talking. Organizations that ..."

    Doesn't anyone proof read these, or shall we all just strt txt spkng?

  3. Anonymous Coward
    Anonymous Coward

    @Mark Fenton

    I don't recognise the first as being a mistake. It's perfectly acceptable English.

    I'd be much more interested if you had something to say on the subject of security, that being the purpose of the article.

  4. Anonymous Coward
    Anonymous Coward

    It is an infomercial

    And it is quite interesting if you go and check out the API the guy has obviously used on the Aspect Security site, surely he must practice what he preaches.

    Basically it revolves around not accepting user generated data at all, not running sessions, though do get some weird cookies, and a pinch of flash, nice to see google analytics makes an appearance as well. And if you access via https, well the certificate reveals itself for the mail host instead.

    Case of the cobbler's shoeless children perhaps.

    I do sort of agree with the idea though, but the problem is not the coders, it is not the developers, it is the clients. And it is the same reason I would guess, that Aspect doesn't have another cert, or the site doesn't interact: money and time.

    Sure, there are some young cowboy developers who are just getting to grips with security, and sure mistakes are made all the time.

    But the truth of the matter is, it is really hard to sell security to a client, they just don't want to pay much for it. Unless they have just had a compromise, it is so far off the radar for them.

    And the API approach is well, cumbersome if you spread it across an organization.

    Instead you should develop an application which understands tainted data, and how to handle it. It is not that hard to do.

    The problem with the API idea, is when the API guys get it wrong, then the other devs go in and change the API for that application, but it doesn't necessarily get passed on to other applications, and depending upon the reason, in some instances it might not actually work for other applications. in effect you have added another layer that may need work on it. And you loose flexibility as well, depending upon how that API is implemented and maintained. Better to see an application as a distinct unit that can interface with the other applications of an organization's systems.

    And then there is scope creep time, you don't want to fob the client off on everything, and you know you are not really getting paid for it. So, you specify the time it will take to do it properly, but they want to release, and the budget is tight, so you hack it in. The client is amazed at your skills, you feel dirty, and the software starts to play dice.

    The real solution to security is to throw money at it, and monitor all the time, but that is obviously expensive, security will always eat into profit no matter what you do. It is like an army, unless you invade and plunder it costs for the defense. Business likes their defense to come from taxes, and if it employs its own security, it tends to do it on the cheap.

    So, security will always be sold through fear or silver bullet solutions, the later will always have a hidden cost and something in it which is assumed to be perfect, but is itself flawed.

    And there is always insurance.

  5. Lou Gosselin

    Re: It is an infomercial

    >But the truth of the matter is, it is really hard to sell security to a client, they just don't want to pay much for it. Unless they have just had a compromise, it is so far off the radar for them.

    I take issue with this statement only because security shouldn't be an afterthought. Especially when some of the vulnerabilities are so trivial to avoid by being consistent in the first place. Encoding fields may require a little more typing, but it hardly requires any additional thought. Unless one is looking at getting a new contract to fix one's bugs, then the cost really should not factor in.

    >I do sort of agree with the idea though, but the problem is not the coders, it is not the developers, it is the clients.

    We disagree here as well, bad security is usually caused by incompetent developers. Some of the glaring holes are unbelievable. Why did these people get hired, they should have known better. Even experienced developers might not be aware that storing database connection strings in viewstate is evil for the same reason that passing security credentials in the URL is. Homegrown string encryption is very common and as stated in the article, is usually flawed.

    Admittedly some attacks are quite involved, intricate, even clever. It's just disappointing to see so many IT shops failing at such a basic level. If the jobs only go to shops with the lowest bid, there is really no incentive to improve.

This topic is closed for new posts.

Other stories you might like