18 Feb '10 20:48>
http://cwe.mitre.org/top25/index.html
Originally posted by zeeblebotAnd 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.
http://cwe.mitre.org/top25/index.html
Originally posted by twhiteheadIf 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" ?
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.
Originally posted by jaywillYou 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.
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" ?
Originally posted by twhiteheadTrue. 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.
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.