No matter what your role is when developing software, it’s useful to have a checklist to follow to make sure the design and the code meets a minimal bar. I have to be honest and say that while checklists are useful, simply following a checklist does not mean you will write secure code, but it’s a reasonable start and it’s useful for new employees. I once overheard a developer point to his group’s security checklist and utter to a new hire, "If you don’t meet this bar, you’ll be in trouble!"
Be aware that this is a minimal checklist. A softcopy is available in the Security Templates folder in the book’s companion content. You should take this document and add your own policy, and the document should be updated regularly as new flaw categories are discovered.
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
Code compiled with –GS (if using Visual C++ .NET) |
5 |
|
o |
Debug builds compiled with –RTC1 (if using Visual C++ .NET) |
5 |
|
o |
Check all untrusted input is verified prior to being used or stored |
10 |
|
o |
All buffer management functions are safe from buffer overruns |
5 |
|
o |
Review Strsafe.h for potential use in your code |
5 |
|
o |
Review the latest update of dangerous or outlawed functions | |
|
o |
All DACLs well formed and "good"—not NULL or Everyone (Full Control) |
6 |
|
o |
No hard-coded 14-character password fields (should be at least PWLEN + 1 for NULL, PWLEN is defined in LMCons.h, and is 256) |
23 |
|
o |
No references to any internal resources (server names, user names) in code |
23 |
|
o |
Security support provider calls not hard-coded to NTLM (use Negotiate) |
16 |
|
o |
Temporary file names are unpredictable |
23 |
|
o |
Calls to CreateProcess[AsUser] do not have NULL as first argument if you know the full path name to the .EXE |
23 |
|
o |
Unauthenticated connections cannot consume large resources |
17 |
|
o |
Error messages do no give too much info to an attacker |
24 |
|
o |
Highly privileged processes are scrutinized by more than one person—does the process require elevated privileges? |
7 |
|
o |
Security sensitive code is commented appropriately |
23 |
|
o |
No decisions made on the name of files |
11 |
|
o |
Check that file requests are not for devices (i.e., COM1, PRN, etc.) |
11 |
|
o |
No shared or writable PE segments |
23 |
|
o |
No user data written to HKLM in the registry |
7 |
|
o |
No user data written to c:program files |
7 |
|
o |
No resources opened for GENERIC_ALL, when lesser permissions will suffice |
7 |
|
o |
Application allows binding to appropriate IP address, rather than 0 or INADDR_ANY |
15 |
|
o |
Exported APIs with byte count vs. word count documented |
5 |
|
o |
Impersonation function return values checked |
23 |
|
o |
For every impersonation, there is a revert |
7, 23 |
|
o |
Service code does not create windows and is not marked interactive |
23 |
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
No Web page issues output based on unfiltered output |
13 |
|
o |
No string concatenation for SQL statements |
12 |
|
o |
No connections to SQL Server as sa |
12 |
|
o |
No ISAPI applications running in process with IIS 5 |
13 |
|
o |
Force a codepage in all Web pages |
13 |
|
o |
No use of eval function with untrusted input in server pages |
13 |
|
o |
No reliance on REFERER header |
13 |
|
o |
Any client-side access and validity checks are performed on the server also |
23 |
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
IDL file(s) compiled with /robust |
16 |
|
o |
[range] used if appropriate |
16 |
|
o |
RPC connections are authenticated |
16 |
|
o |
Use of packet privacy and integrity investigated |
16 |
|
o |
Strict context handles used |
16 |
|
o |
Context handles != access checks |
16 |
|
o |
NULL context handles correctly handled |
16 |
|
o |
Access is determined by security callbacks |
16 |
|
o |
Implications of multiple RPC servers in a single process investigated |
16 |
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
All ActiveX controls, marked as safe for scripting, are indeed safe |
16 |
|
o |
SiteLock use investigated |
16 |
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
No embedded secret data (EXE, DLL, registry, files, etc.) |
9 |
|
o |
Secret data is secured appropriately |
9 |
|
o |
Calls to memset/ZeroMemory on private data are not optimized away. If they are, replace with SecureZeroMemory. |
9 |
|
o |
No home-developed crypto code—use CryptoAPI or System.Security.Cryptography |
8 |
|
o |
Random number generation reviewed |
8 |
|
o |
Password generation is random |
8 |
|
o |
RC4 code does not reuse an encryption key |
8 |
|
o |
RC4-encrypted data has integrity checking |
8 |
|
o |
No weak crypto (128-bit vs. 40-bit) |
8 |
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
FXCop has no security complaints |
18 |
|
o |
No sensitive data in XML or configuration files |
18 |
|
o |
Classes are marked final, if appropriate |
18 |
|
o |
Inheritance demands on classes, if appropriate |
18 |
|
o |
All assemblies are strong-named |
18 |
|
o |
Assemblies use RequireMinimum to define the must-have grant set |
18 |
|
o |
Assemblies use RequestRefuse to reject specific permissions |
18 |
|
o |
Assemblies use RequestOptional to outline optional permissions that may be required |
18 |
|
o |
Assemblies that allow partial trust are thoroughly reviewed and have a valid partial-trust scenario |
18 |
|
o |
Demand appropriate permissions |
18 |
|
o |
Assert is followed by RevertAssert to keep time of asserted permission small |
18 |
|
o |
Code that denies access based on a filename is carefully checked |
18 |
|
o |
Assert trumps calls to PermitOnly and Deny further up the stack. Check code that attempts to operate otherwise. |
18 |
|
o |
LinkDemand thoroughly audited for correctness. Are link demands really required? |
18 |
|
o |
No stack trace provided to untrusted users |
18 |
|
o |
SuppressUnmanagedCodeSecurityAttribute used with caution |
18 |
|
o |
Managed wrappers to unmaged code checked for correctness |
18 |