前言

昨天有兄弟看到我文章里的帖子提到的T氏法則，其實有點吹的成分了哦（很多也都是和同事整理的，也有客戶強制要求的），大部分由于很凌亂沒有正式的版本，所以先發一部分出來（Security方面的）。由于是歐美項目，所以資料全都是英文版的，各位湊合著看吧。

正文

Input Validation

1. Is input data validated to ensure that it contains only valid characters?
2. Is input data validated to ensure that it is within appropriate ranges?
3. Is validation performed by comparing with "known-good" (as opposed to "known-bad") characters or sequences?

Output Encoding

1. Is data encoded using HTMLEncode (or similar function) when forwarding to display in the browser?
2. Is data provided as parameters to a parameterized SQL query (as opposed to concatenation into the query)?
3. Are steps taken to avoid SQL injection, Cross Site Scripting or other injection attacks (where appropriate)?
4. When supplying code and data as output, is it unambiguously clear where code and data are separated?

Information Exposure

1. Do error messages distinguish correctly between information sent to internal and external users?
2. Are comments and private information removed from transmissions to the user?
3. Are internal IP addresses masked from external users?
4. Are debug pages, and unused pages removed from the deployed web site?
5. Is debug and tracing code disabled, with no ability for unauthorized parties to use it or enable it?

Client-Side Security

1. Are security measures such as input validation implemented on the server-side?
2. Are all security measures implemented on the client-side backed by equivalent or greater measures on the server-side?
3. Has the application (or changed components) been tested with custom clients that ignore client side restrictions?

Poor Use of Cryptography

1. Have cryptography choices (key sizes, algorithms, etc.) been reviewed and approved by Policymakers?
2. Are cryptographic elements configurable to change key sizes, choice of algorithms, etc.?
3. Is the cryptography implementation a widely-available library (as opposed to a custom solution, or developed in-house)?
4. Is provision made for regular key rotation? Emergency key changes?

Thinking Only About Features

1. Has the application been tested by trying to feed it invalid input?
2. Have there been any tests attempting to use SQL Injection, Cross-Site Scripting, etc.?
3. Has the application been written to reject incorrect or malicious data?
4. Does the application alert its operators about potential malicious behavior on the part of its users?
5. Does the application alert its operators about (mis-)configurations that reduce its security level?
6. Has the application been reviewed to ensure that unauthenticated and unauthorized users are not given more access than is appropriate?

Race Condition

1. Is the code flexible enough to cope with resource requests completing earlier / later than anticipated?
2. Are checks on authorization guaranteed to occur before access is granted or resources are fetched?
3. Is the application able to handle rapidly repeated requests and distinguish correctly between them?
4. Does the application ensure that connection state is kept out of global / shared variables or memory space?
5. Are locks, mutexes, semaphores, etc. correctly used to ensure that shared resources are not shared across execution or security contexts?
6. Has the review team considered changes that will occur if the compiler / optimizer change the order of execution of statements (within its limits)?

Failing Open, Ignoring Failure

1. Are all return values checked?
2. Where exceptions are expected, are they all caught?
3. Is checking of correct input done by “deny by default” (e.g. a “white-list” of correct characters / sequences)?
4. Are functions communicating failures up through their call stack?
5. Is the code written to assume that requests are invalid until they prove themselves to be valid?

Failing to Recognize or Enforce Bounds

1. Are all arithmetic operations guaranteed to not overflow or underflow?
2. Are buffer overflows actively prevented, either by choice of development environment, language or code checks?
3. Are classes and libraries used that prevent overflow or underflow (as opposed to classes that do not)?
4. Are library functions prown to buffer overrun, removed and replaced with?
5. Does the test plan execute edge cases on boundary checks?
6. Have you checked the entrance and exit criteria for all loops in the code to ensure that they are correct, and correctly handled?

Not Managing Resources from Creation to Destruction

1. Does each resource have a complete “story” that allows for a single creation and a single destruction, with managed ‘ownership’ in the middle?
2. Does the test plan monitor resource usage to detect inappropriate growth in memory usage, open file handles, etc.?
3. Do object constructors initialize all member variables (if only to a null value)?
4. Do object constructors avoid using operations that can cause failure?
5. Are circular references correctly avoided?

Hard-Coded Password/Assuming the Source Code Is Selected

1. Are all passwords, keys and other secret material removed from source code to configuration files?
2. Has the executable code been scanned for the clear-text presence of strings that should not be there?
3. Does the code use a standard, EIS-approved, technique for storing keys in configuration files?
4. If the source code was given, as a whole, to an attacker, would they still be unable to attack the running program?

Unnecessary Complexity

1. Is the code clear to read and understand, even without looking at the comments?
2. Do the comments correctly describe the behavior of the source code?
3. Do the comments completely describe the behavior of the source code?
4. Are any hidden / surprising / clever behaviors of the source code explained in comments?
5. Are the comments up to date?
6. Have all unexecuted portions of code been removed?
7. Are function and variable names clear and meaningful?

Static Code Analysis

1. Has the code been analyzed with static code analysis tools that are configured to find security flaws?
2. Have all new reports of possible security flaws been remediated correctly?

同步與推薦

本文已同步至目錄索引：《大叔手記全集》

大叔手記：旨在記錄日常工作中的各種小技巧與資料（包括但不限于技術），如對你有用，請推薦一把，給大叔寫作的動力