| |||||||||||
|
| |||||||||||
Language versus application securityLanguage versus application securityPosted Jan 30, 2003 12:36 UTC (Thu) by copsewood (subscriber, #199)In reply to: A look at the MS-SQL worm by NAR Parent article: A look at the MS-SQL worm 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.
(Log in to post comments)
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.
|
|||||||||||