| |||||||||||||
|
| |||||||||||||
A look at the MS-SQL wormA look at the MS-SQL wormPosted Jan 30, 2003 11:11 UTC (Thu) by NAR (subscriber, #1313)In reply to: A look at the MS-SQL worm by skellba Parent article: A look at the MS-SQL worm It would be better to not use programming languages like C or C++ which are inherently prone to buffer overflows and memory overwrites. I heard once a guy, who proudly announced his 100 line long secure webserver written in perl, and asked folks to audit it. Of course, it is not that hard to audit 100 lines of code, even if it's written in perl :-) But don't forget, that the C code of the perl interpreter should be audited also, and that is not 100 lines long...
(Log in to post comments)
Language versus application security Posted Jan 30, 2003 12:36 UTC (Thu) by copsewood (subscriber, #199) [Link] I think the people who design and implement very high-level programming languages (e.g. Perl, Python, Java, SQL, - 'C' is too low-level) are somewhat more likely to be able to write interpreters secured against buffer overflows etc. than the people likely to be writing network-based applications which use these tools, due to the likely differences in programming knowledge and experience.Hence it is likely that an application designer needs less security knowledge to design a reasonably robust web application in Perl (which does the memory management housekeeping within the language) than in 'C' (which manages memory within the application). Not only that but the ISP hosting virtual domains is likely to want to patch insecurities discovered in the language runtimes much quicker than most of the domain owners will patch insecure web applications.
Language versus application security Posted Jan 30, 2003 18:21 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Perl doesn't have buffer overflows, but Perl-based web applications have had tons of security holes, mostly caused by not sufficiently checking user-supplied data (../../.. in paths, cross-site scripting, and the like).
Language versus application security Posted Jan 31, 2003 0:54 UTC (Fri) by copsewood (subscriber, #199) [Link] Yep. The approach of deciding what valid data should look like and excluding everything else is similar to the default-deny approach to firewall setups. This can reduce functionality slightly or slightly increases the effort of getting added functionality secure, but its probably much less hassle than trying specifically to exclude what is considered dangerous when you can only ever have limited knowledge of what might be exploitable in future.
|
|
||||||||||||