Web Security Flashcards
1
Q
Daemons: Threats
A
- Daemons are long running:
-> ASLR/stack canaries are probabilistic, single secret per process/thread
-> Heap layout influenced by concurrent allocations
-> Information leaks become more dangerous - Daemons are complex:
-> Crashing threads are restarted: resilience/uptime versus security
-> Large set of functionalities increases attack surfaces
-> Shared secrets across users in single address space - Daemons are exposed:
-> Services concurrent users (in the same address space)
-> Outside connections are allowed
-> Attackers can leverage many diverse IPs
2
Q
Protecting daemons/services
A
- Daemon compartmentalization:
-> Break complexity into smaller compartments
-> Develop “fault compartments”, can fail independently
-> Goal: once component fails, others continue to function
3
Q
OWASP Top 10
A
- Broken Access Control
- Cryptographic Failures
- (Code) Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and outdated components
- Identification and authentication failures
- Software and data integrity failures
- Security Logging and Monitoring Failures
- Server Side Request Forgery
4
Q
Broken Access Control
A
- Restrictions on what authenticated users are allowed to do are often not properly enforced
- Attackers gain access to unauthorized functionality and/or data
5
Q
Broken Access Control: Protection
A
- Except for public resources deny access by default
- Limit exposure (reduce log information to error code)
- Disable directory listing
- Rely on central access control
- Rate limit API calls and enforce access checks
- Log access control failures (and check the logs!)
6
Q
Cryptographic Failures
A
- Sensitive data is not protected well enough
- Attackers may steal or modify it
- Goals:
-> Store and process the minimum amount of sensitive data
-> Separate and segregate data into compartments
-> Create data policies that record where, how, and what data is processed
7
Q
Cryptographic Failures: Protection
A
- Be aware of what data types are handled (threat modeling)
- Only store what you need, nothing more
- Protect data at rest and in transit (e.g. through encryption)
- Only store password hashes
8
Q
Code Injection
A
- Untrusted data is sent to an interpreter as part of a command or query
- Allows for execution of unintended commands or accessing data without proper authorization
9
Q
Code injection: Protection
A
1) Validation
- Ensure that filename matches a set of allowed filenames
- Non-alphanumeric characters are needed to execute commands
- Hardcode directory and set of allowed files
- Disallow special characters in the file name
2) Escaping
- Escape parameters so that interpreter can distinguish between data and control
3) Reduction of privileges
10
Q
A
11
Q
Cross-Site Scripting: Protection
A
- Modern frameworks allow you to properly escape input. Each framework has its subtleties
- Use the provided escape functionality and review the code
- Leverage data-flow to detect where unfiltered input exists
12
Q
Insecure design
A
- Lack of threat modeling
- Lack of focus on secure design patterns and principles
- Fuzzy “catch all” area that covers any abstract issues
13
Q
Security Misconfiguration
A
- Insecure default configurations
- Incomplete or ad how configurations
- Open cloud storage
- Misconfigured HTTP headers
- Error messages containing sensitive information
- All components must be patched and upgraded in a timely fashion
14
Q
Security Misconfiguration: Protection
A
- Configuration documentation (what software is in use, in what configuration?)
- Keep your systems up to date
- Use compartmentalization
- Review for configuration failures
15
Q
Vulnerable and Outdated Components: Protection
A
- Remove unused dependencies
- Documentation of components and dependencies
- Monitor for unmaintained libraries or components
