> "There is no such thing as dangerous functions, only dangerous
> developers."*
Perl's print statement is safe, right? No buffer overflows *there*...
print 'Hello, '.$query->param('name');
Except now I'm vulnerable to cross-site scripting :)
apl
----- Original Message -----
From: "Michael Howard" <mikehow (at) microsoft (dot) com [email concealed]>
To: <phani (at) myrealbox (dot) com [email concealed]>; <secprog (at) securityfocus (dot) com [email concealed]>
Sent: Friday, November 15, 2002 7:00 PM
Subject: RE: Are bad developer libraries the problem with M$ software?
"There is no such thing as dangerous functions, only dangerous
developers."*
"secure" functions are a complete crok - there is no such thing... There
are some functions that help you get things right, but they do not lead
to secure code... Anyone who thinks they can do away with the
"dangerous" functions and replace them with the "safe" 'n' versions (ie;
strcpy -> strncpy) is kidding themselves.
The issue is the DATA, not the code. Do you trust the data? You need to
determine at which point in the code is the data well-formed and
correct. The ONLY way to build secure code is to question the
assumptions about the trustworthiness of the data as it crosses
untrusted to trusted boundaries, not hunting down "insecure" functions.
> developers."*
Perl's print statement is safe, right? No buffer overflows *there*...
print 'Hello, '.$query->param('name');
Except now I'm vulnerable to cross-site scripting :)
apl
----- Original Message -----
From: "Michael Howard" <mikehow (at) microsoft (dot) com [email concealed]>
To: <phani (at) myrealbox (dot) com [email concealed]>; <secprog (at) securityfocus (dot) com [email concealed]>
Sent: Friday, November 15, 2002 7:00 PM
Subject: RE: Are bad developer libraries the problem with M$ software?
"There is no such thing as dangerous functions, only dangerous
developers."*
"secure" functions are a complete crok - there is no such thing... There
are some functions that help you get things right, but they do not lead
to secure code... Anyone who thinks they can do away with the
"dangerous" functions and replace them with the "safe" 'n' versions (ie;
strcpy -> strncpy) is kidding themselves.
The issue is the DATA, not the code. Do you trust the data? You need to
determine at which point in the code is the data well-formed and
correct. The ONLY way to build secure code is to question the
assumptions about the trustworthiness of the data as it crosses
untrusted to trusted boundaries, not hunting down "insecure" functions.
Here's an example: wassup with this code?
#define MAXSTRLEN(x) (sizeof(x)/sizeof(x[0]))
if (bstrURL != NULL) {
WCHAR szTmp[MAX_PATH];
LPCWSTR szExtSrc;
LPWSTR szExtDst;
wcsncpy( szTmp, bstrURL, MAXSTRLEN(szTmp) );
szTmp[MAXSTRLEN(szTmp)] = 0;
szExtSrc = wcsrchr( bstrURL, '.' );
szExtDst = wcsrchr( szTmp , '.' );
if(szExtDst) {
szExtDst[0] = 0;
if(m_inst.m_fDesktop) {
wcsncat( szTmp, L"__DESKTOP", MAXSTRLEN(szTmp) );
wcsncat( szTmp, szExtSrc , MAXSTRLEN(szTmp) );
It's secure, right? 'coz I'm using the 'secure' 'n' versions!!!? No,
it's not.. I'll leave that as an exercise for the reader
* there is one function that is impossible to use securely -> gets() :-)
Cheers, Michael
Secure Windows Initiative
Writing Secure Code
http://www.microsoft.com/mspress/books/5612.asp
[ reply ]