Introduction
Laymen explanation
Technical explanation
Program intended behaviour is derived from user need. However, most of times, actual behaviour doesn't exactly overlap with intended behaviour. These deviations are exploited by attacker for its intent.
Coding defect types
CWE (Common Weakness Enumeration) provides list of common software security defects
SQL injection
Attacker submits the query as piggybacking with normal query
Mitigation-Use parameterised API (prepared statement) for accepting SQL query
OS command injection
Attacker submits OS command
Mitigation-Use parameterised API
Buffer overflow
C/C++ allow programmer to perform memory management
Mitigation-Restrict buffer size
Cross site scripting
User can implant a malicious script in web-server. And then access it via web link. Another example to access session cookie
Mitigation- Input validation, encode untrusted data
Missing authentication for critical operation
User can directly perform critical operation
Mitigation- Add authentication. Review code
Missing authorisation
User can access critical resource
Mitigation- Add authorisation, Review code, Divide between sensitive and not sensitive resources
Hard-coded credential
Anyone access to code can recover the credential
Mitigation - Never hard-code credential, Review code
Missing encryption of sensitive data
Data can be taped on wire
Mitigation - Encrypt data using strong method
Unrestricted upload of file with dangerous type
Attacker can upload dangerous file and then access via web to compromise the client. For example, it can upload dangerous script and then load in the browser
Mitigation- Validate the file, reference name, don't allow user to name the file
Untrusted input for security decision
Attacker can provide manipulate the parameter (for example, parameter which can increase privilege level)
Mitigation- Validate input parameter
Unnecessary privilege
Internet explorer was running at high privilege which caused many attacks on client machine
Mitigation - policy of least privilege
Cross site request forgery
???
Path traversal vulnerability
Attacker will traverse the path to get files which are not supposed to be exposed
Mitigation - reference map, access control check
Download code without integrity check
Attack change the code during download
Mitigation - Integrity check of the downloaded code
Incorrect authorisation
Attacker use lesser authorised resource which actually needs high authorization
Mitigation - Code review
Allow to load code without check from untrusted source
Mitigation - Check signature
Dangerous function
For example eval()
Risky cryptographic functions
Open redirect
Attacker will redirect to malicious site
Mitigation - Notify user, reference map, review code
One way hash without salt for storing password
Robust code suggestion
Input validation
Use whitelist approach for input validation, not the blacklist approach
Use regular expression to validate input
Some validation like range can't be done via regular expression
Encryption method
Use strong encryption method
Random number generator
Check for return value as it may return error
Encryption key generation
Use key derivation function based on user password
Cipher mode
Use appropriate mode
Encryption libraries
Use widely acceptable libraries
Buffer overflow handling
Mention the size in copy operation
Don't use unsafe API like strcpy
Use Stack security cookies based compiler
Use ASLR approach. OS randomise the library API path
gcc complier uses -fpie option for this
No Execute(NX) policy
CPU is instructed the portion of code which is no execution.
JIT compilation can't be used with NX
gcc uses -fstack-protector option for this
Array boundary check
Undefined behaviour in C/C++
Can result in crash, memory leak, exposure of sensitive information
Attacker can exploit implementation specific behaviour
Don't use any code having undefined behaviour
Memory management
Avoid Memory error
Double free
Use after free
Invalid memory pointers
Out of range access
Uninitialised memory
Use smart pointer
On freeing memory, set pointer to Null
Only free memory which you have allocated
Never throws exception on deallocation
Always free memory using matching deallocation function
Limiting memory exposure
Avoid creating multiple copies of sensitive data
Remove plaintext after encryption
Don't decrypt unless needed
clear memory after finish using sensitive data
Prevent disk paging of sensitive data
Not possible since OS saves sensitive data to disk on hibernate
Disable core-dump to avoid core-dump of sensitive data (setrlimit API in unix)
Race condition avoidance
Canonicalisation path issue??
-flto -funsafe-math-optimizations -fstack-protector-strong
Useful link - https://www.unixteacher.org/blog/build-options-to-improve-the-performance-and-security-of-nginx/