Secure Coding mailing list archives
Re: Checking values
From: carolyn.ryll () philips com
Date: Sat, 06 Dec 2003 17:18:23 +0000
Wouldn't logic state that you should be paranoid outside your own circle of proven trust? If you do not know if validation is assured, then test it. If the test fails, then you know you need to validate it at your end. Truly not meant as a Microsoft OS slam, but you are putting trust in classes that Microsoft certainly uses themselves - and they are the KingPin of the buffer overflow vulnerability. Documented doesn't mean anything, either. Documentation is usually written by tech-writers who clean up documents thrown together by the designers and programmers (that documented after the fact), and have never stepped foot into the development process. Like I said, if it's not in your *proven* circle of trust, then why should you trust it? Regards, Carolyn. Chris Richards <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2003-12-05 10:19 AM To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: (bcc: Carolyn Ryll/ATL-BTL/MS/PHILIPS) Subject: [SC-L] Checking values Classification: Here's a question: How paranoid should I be in checking values? For example: I frequently have need to check registry keys for values, so I commonly do something like the following: CRegKey crReg; CString csValue; DWORD dwBuffSize = 1024, dwReturn = 0xFFFFFFFF; TCHAR *lpszValue; //code to open registry . . . //get reg value lpszValue = csValue.GetBuffer(dwBuffSize); if(NULL != lpszValue) { dwReturn = crReg.QueryValue(lpszValue, "SomeRegistryValueName", &dwBuffSize); csValue.ReleaseBuffer(dwBuffSize); lpszValue = NULL; if(ERROR_SUCCESS != dwReturn) { //do error processing } } //other processing These are all MFC classes. CString is documented as initializing itself to a null string. Should I believe the docs, or should I initialize the string anyway? If I don't believe it, then what is the point of using the class (one of the reasons you use classes is because the constructors and destructors are supposed to take care of house-keeping issues like this for you)? If I assume that it is correct and it turns out not to be, do I bear some of the blame for the failure of the application? In short, how far do we go in assuming the rest of the world is out to get us? If I create a function, and document that only certain input ranges are valid and that unpredictable behavior may result if you violate those bounds, is it my fault if someone violates those bounds when using my function? Generally speaking, my rule of thumb has always been to assume that direct user input is hostile, because users are dumb and will ignore all of the warnings that you give them. On the other hand, if the design of an application guarantees that a function requiring input data within a certain range will only ever see data within that range, I may not do any bounds checking within that function, though I will document the range of inputs the function expects. The exception to this is in cases where I am writing a function specifically for general use, where the range of inputs may violate expectations. What say you? And why? Later, Chris
Current thread:
- Checking values Chris Richards (Dec 05)
- <Possible follow-ups>
- Re: Checking values carolyn . ryll (Dec 06)
- Re: Checking values Peter G. Neumann (Dec 07)
- RE: Checking values Brown, James (Jim) (Dec 07)