Sofrware Security Flashcards
Software Security (Quality and Reliability)
caused by poor programming techniques
- improve methods for specifying and building sw
- finding vulnerabilities before they can be exploited
- reducing impact of vulnerabilities
Defensive/Secure Programming
design/implement sw continues to function even when under attack.
detect erroneous conditions and continue safely or fail gracefully.
check all assumptions and handle any possible error states
check any assumptions made, check and handle all possible errors, carefully check any interactions with existing code
fail to see this -> incorrect program behavior and introduction of vulnerabilities
awareness of the consequences of failure and the techniques used by attackers
Handling Program Input
use of safe string and bugger copying routines, also checking the buffer limits in runtime
processing the input in blocks, discarding excess input, terminating program in case of overflow
Heartbleed failing to check total of data requested to be returned
buffer over-read
injection attacks -> invalid handling of input data
shell metacharacters -> used to separate or combine multiple commands (;)
command injection attack
input is used in a command exec’d by the system with higher privileges
SQL injection
user supplied input used to construct a sql query to obtain unauth information
SQL placeholders or parameters and stored procedures -> more robust and secure code
PHP file inclusion vulnerability -> block assignment of form field values to global variables, only use constant values in include and require commands (code indeed generates from the specified file)
mail, format string and interpreter injection
Handling Program Input - XSS attacks Cross site scripting
all content from one site is equally trusted and hence permitted to interact with other content from that site
exploit assumption bypass browser’s security checks to gain privileged access to sensitive data
XSS reflection vulnerability -> attacker includes malicious script content in data supplied to a site. When displayed to other user it will execute without proper checking
Handling Program Input - Validating Input Syntax
whitelisting over blacklisting because is easier to define the format of what is associated as valid input regex
error message should be shown to ask correction and reentering - escaping metacharacters to clean input
ASCII 8bit 128 values
Unicode 1-4 bytes UTF-8. accepts longer but strict only shortest should be used
/ -> 2F short; CO AF long, E0 80 AF long
attach to do path traversal -> must check / and variations are not present
with multiple possible encodings -> single, standard,minimal representation must be used (canonicalization)
buffer size = unsigned integer (depends on language) may be trated as signed value a negative value as top bit is set . same bit used for large unsigned integers
attack = specify a very large actual input data length, trated as a neg number when compared with the max buffer size
Handling Program Input - Input Fuzzing
used in testing to generate large amounts of abnormal inputs to test whether the system crashes or fails
its simple and free from assumptions
identifies reliability and security deficiencies
generated based on templates
flaws -> only identifies simple types of faults with handling of input
bug by small number of very specific input values not able to locate it
black box test tools + fuzzing tests to identify bugs
Writing Safe Program Code - Correct Algorithm Implementation
Deficiency in the design or implementation of an algorithm is a bug -> inappropriate handling of what should be valid input
Netscape - inadequate random number generator poor choice easy to predict numbers, possible for attackers to decrypt data exchanged in sessions
TCP session spoof or hijack attack -> sending spoofed packets to a TCP server
spoofed packets can guess seq number and get rights assigned to it
session hijack -> legitimate user tries to auth, attacker spoofs packets, gets rights from legitimate user
DDoS attack to spoofed source while doing the hijack to target server to avoid having legitimate packets steal the session
TCP seq numbers are too predictable
Use of formal methods in software development and analysis to ensure software is correct by construction
Writing Safe Program Code - Ensuring that Machine Language Corresponds to Algorithm
malicious compiler could include instructions in the compiler to emit additional code when some specific input were processed
malicious routines could be only in machine code
Trusted Computer Systems, level of checking EAL 7
Writing Safe Program Code - Correct Interpretation of Data Values
strong typing prevents inappropriate manipulation and misuse of variables introducing flaws
C suffers from inappropriate manipulation and use of pointers due to similarity between integers and memory addresses
monitor system and try not to use routines with known serious bugs + use strongly typed languages
Writing Safe Program Code - Correct Use of Memory
incorrect handling of allocated memory might exhaust memory in heap to the point of a memory leak this could cause a DDoS attack
automatically managing memory causes an execution overhead but is more reliable
without synchronization to access memory regions values can be corrupted, lost due to overlapping access, use, and replacement -> race condition
if incorrect sequence of syncrhonization primitives is chosen -> deadlock waiting on held resource
Interacting with OS and other apps
Environment variables -> collections of string values inherited by each process from parent affect running process
PATH directories to search for command
IFS word boundaries in shell script
LD_LIBRARY_PATH directories to search for dynamically loadable libraries
attack is coerce user on system attempting to gain increased privileges
discouraged use of privileged shell scripts
change group and reset all critical environment variables -> attack cannot gain superuser privileges
dynamically loaded libraries -> dynamic linking
it does not include the code
allows to have dynamic definition on which libraries to use per system but introduces an attack possibility
attacker creates a copy of the library and the target program uses it instead of the legitimate own
Defense -> use statically linked exec at a cost of memory efficiency
some OSs block the env variable when the program runs with different privileges
all programs should execute with the principle of least privilege
servers that need to bind to privileged ports can changed the desired port after binding
chroot jail only access to files in chroot jail section
Interacting with OS and other apps - Preventing race conditions
using a lockfile, although program might still ignore it
check and creation of lockfile must be an atomic operation -> always attempt to create it
some programs store a temporary copy of the data while processing. they are unique and not accessed by other processes
attack guessing lockfile and making another program use it with a symlink to the pwd file so it overwrites it
Output validity and interpretation
check output really does conform to the expected form and interpretation, it stems from the assumption of common origin and that the previous program did all possible checks
XSS attacks
