1. silicon valley
    Joined
    27 Oct '04
    Moves
    101289
    18 Feb '10 20:48
    http://cwe.mitre.org/top25/index.html
  2. Cape Town
    Joined
    14 Apr '05
    Moves
    52945
    19 Feb '10 18:26
    Originally posted by zeeblebot
    http://cwe.mitre.org/top25/index.html
    And I thought 'dangerous' meant 'the program might cause grievous bodily harm', when what you really mean is 'insecure', which for many of us programmers doesn't really matter as we are not storing particularly sensitive data, and the people who might want our data simply don't have the skills to take advantage of buffer overflows and SQL injection etc.
  3. Joined
    02 Aug '06
    Moves
    12622
    20 Feb '10 13:44
    Originally posted by twhitehead
    And I thought 'dangerous' meant 'the program might cause grievous bodily harm', when what you really mean is 'insecure', which for many of us programmers doesn't really matter as we are not storing particularly sensitive data, and the people who might want our data simply don't have the skills to take advantage of buffer overflows and SQL injection etc.
    If you're processing millions of records and performance is an issue, how much turnaround slowdown are you likely to get because of giving detailed care to buffer overflow and "SQL injection" ?
  4. Subscribersonhouse
    Fast and Curious
    slatington, pa, usa
    Joined
    28 Dec '04
    Moves
    53223
    21 Feb '10 03:58
    Originally posted by jaywill
    If you're processing millions of records and performance is an issue, how much turnaround slowdown are you likely to get because of giving detailed care to buffer overflow and "SQL injection" ?
    I guess that's one reason to develop way faster computers.
  5. Cape Town
    Joined
    14 Apr '05
    Moves
    52945
    21 Feb '10 07:032 edits
    Originally posted by jaywill
    If you're processing millions of records and performance is an issue, how much turnaround slowdown are you likely to get because of giving detailed care to buffer overflow and "SQL injection" ?
    You are probably right that increase security results in a performance hit. However I suspect that for many of us the cost hit in terms of programmer time is more significant.
    This whole discussion reminds me of the Windows / Linux situation.
    Linux was very successful on servers because of its security.
    Windows was successful on the desktop because of its ease of use and backward compatibility - both of which resulted in poor security.
    Microsoft spent lots of effort trying to make Windows more secure resulting in it being harder to use and more annoying.

    The lesson for me is that though security is important, you can over do it in situations where it is not really required.

    The number one cause of virus' in my part of the world is all due to the fact that Windows has auto-play turned on for flash drive by default. If they simply sent out a patch that turned that off then that would eliminate 90% of virus' around here. It can be turned off manually but not many people know that.
  6. Joined
    07 Sep '05
    Moves
    35068
    22 Feb '10 11:071 edit
    Originally posted by twhitehead
    You are probably right that increase security results in a performance hit. However I suspect that for many of us the cost hit in terms of programmer time is more significant.
    True. Although in most languages protecting yourself against injection attacks is just a matter of "doing it properly". It's not really any more difficult or slower.

    And to follow up the earlier comment - I'd be hard pressed to think of an application processing millions of records where performance is an issue and security isn't.
Back to Top

Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.I Agree