Highlighted Topics Flashcards
SQL Injections
Injection might happen when queries are built using (e.g. concatenating) the parameters provided by the users
SQL Injection Example
$query = “SELECT ssn FROM employees WHERE name = ‘“ + username +”’ ”
SQL Injection Solutions
Prepare statement allows for the clear separation of what is to be considered data and what is to be considered code
1) query is parsed and location of the parameters are identified
2) the parameters are bound to their actual value
SQL Injection Solution Example
1) perpare(“… name = ? AND username = ?”);
2) bind_param(“ss”, $name, $password);
Cross-Site Scripting (XSS)
Used to bypass JavaScript’s same-origin policy – malicious JavaScript code that is injected, stored on the server, and then executed.
Since it is stored on the server, the browser interprets the code as the same origin as the server
XSS Prevention
1) Input Sanitation
2) Output Encoding
3) User Frameworks with Built-it XSS Prevention
XXS Prevention: Input Sanitization
Implement robust input sanitization to strip out or encode potentially harmful characters from user inputs
Cannot be trivial since characters can be encoded (e.g. < is read as < and > is read as >)
XSS Prevention: Output Encoding
Ensure any data output to a page is treated as data, not executable code
Encode special characters (<, >, &, “, ‘) to their HTML or URL encoded equivalents
XSS Prevention: Frameworks
Leverage modern development frameworks and libraries that automatically handle input sanitization and output encoding to reduce XSS vulnerabilities
Cross-Site Request Forgery (CSRF)
An attacker induces users to perform action that they do not intend to perform on a web application in which they are currently authenticated (normally using website redirection)
CSRF Countermeasure
Anit-CSRF Tokens which are unique to each user session and embed this token in forms and requests to verify that the submission is intentional and originates from the legitimate user interface
Anit-CSRF Tokens: SameSite = Strict
Browser does not include cookies in any cross-site request
Anit-CSRF Tokens: SameSite = Lax
Allows cookies to be added to request triggered by cross-site top-level navigation
What is setuid?
If stored in setuid file, the permissions of the corresponding process will be equalivalent to the presmission of the owner of the file program
real user ID = user who started the process
effective user ID = owner
Spatial Memory Safety Errors
Out-of-bound Write/Read which can lead to software crashes if non-writable/readable/allocated memory is accessed
Out-of-Bound Read/Write
The software reads/writes data past the end/before the beginning of the intended buffer
Read: can lead to memory disclosure (leak)
Write: can lead to memory corruption
Temporal Memory Safety Errors
Memory is accessed at the ‘wrong’ time
1) Use After Free
2) Accessing uninitialized variables
3) Double free
Use After Free
Software reuses memory after it has been freed. Two pointers incorrectly point to the same region.
Can lead to Memory Disclosure or Memory Corruption
Memory Safety Errors Exploitation
Spatial/temporal memory safety errors can be used to “leak” secrets from program (e.g. heartbleed)
Can be used to achieve arbitrary code execution
Memory Safety Causing
Code Execution
1) Use an out-of-bound write or corrupt a code pointer
2) Make corrupted pointer point to some attacker-controlled data which will then be executed
push
Write a value on the top of the stack
Rewriting push rax:
sub rsp, 8
mob qword ptr [rsp], rax
OR
sub rsp, 8
*rsp = rax
pop
Read a value from the top of the stack
Rewriting pop rax:
mov rax, qword ptr [rsp]
add rsp, 8
OR
rax = *rsp
add rsp, 8
call
Jump to a location, write the return address on the stack
Rewrite call 0x112230
push <address of following instruction>
jmp 0x112230
OR
sub rsp, 8
*rsp = <following>
jmp 0x112230</following>
ret
Return from a call
Rewrite ret
pop rip
OR
jmp qword ptr [rsp]
add rsp, 8
Address Space Layout Randomization (ASLR)
Addresses the assumption that “We know where the address of the attacker-controlled memory is”
Implemented by operating system and randomizes the position of: heap, stack, dynamically-linked libraries, and program’s main code
ASLR Exploitation
Can disabled by “leaking” memory content (e.g. out-of-bound read) especially since common ASLR implementations only shift the entire memory layout by an offset
Non-Executable Memory (NX)
Address the assumption that “The attacker-controlled memory is executable”
No memory page is both writable and executable. The CPU enforces that if the program attempts to execute data in an non-executable memory page an exception is raised
NX Exploitation
If there exists a “win” function already in the code then we can use Code Reuse/Return Oriented Programming (ROP)
Return Oriented Programming (ROP)
Re-use gadgets (such as pop rdi; ret)
We can set the stack so that the execution “jumps” from one gadget to the next one
Control Flow Integrity (CFI)
Enforce that the flow of execution of the program only takes a legitimate path (e.g. ret can only return to its caller)
Hard to
1) cover all possible corner cases and uncommon behaviors legitimate programs may have
2) be efficient since it requires CPU supports
Why is C memory unsafe?
1) Low-level memory access: arbitrarily create pointers at arbitrary locations
2) NO runtime check on the validity of the access memory
3) Manual memory management: need to manually allocate/de-allocate memory buffer (e.g. malloc() and free())
Why is Java memory safe?
1) Automated memory management: if memory is needed, the garbage collector will run and frees memory of memory buffers that cannot be accessed anymore
2) Does not allow arbitrary memory access: accessing null throws a NullPoitnerException (especially since all variable need to be initialized_
3) Runtime array bounds checking: cannot access array out of bounds without throwing ArrayIndexOfBoundsException
Drawbacks of Java
1) Performance impact from added checks
2) Require virtual machine and a large “runtime” library
3) No direct control over memory allocation/free
4) Does not allow fine-tuned memory management
Reasons to use C
1) allows specifying how memory should be accessed and managed
2) allows low-level interaction with peripherals
3) allows writing highly-optimized code
4) is compatible with older systems
Google’s Rule of 2
Can only have at most two of these things be true:
1) code which processes untrustworthy input
2) code written in an unsafe language
3) code which runs with no sandbox (e.g. browser process)
Security Principles: Updates & Andriod
Apps are automatically updated in background
Many system components can be updated without a “full” system update
Security Principles: Defense in Depth
Multiple layers of security controls are placed throughout a system
Prevents single vulnerabilities from leading to compromise of the entire OS or other apps
Android Permissions
Prior to 6, it was all or nothing. Now there are three types of permissions:
1) install-time permissions: cannot be revoked
2) runtime-permissions: need to be approved at runtime
3) special permissions: enabled in ad-hoc ways (accessibility, device administrator)
