Web Security Flashcards
1
Q
CSRF Vorgehen
A
- Attacker sends a prepared URL specific function of the web application
- Opens the web application, where he has logged in earlier and executes the function
- Attacker can login in web application due to password change
2
Q
CSRF Countermeasures
A
- Additional PIN/TAN
- Random (one-time) tokens associated with the user’s current session
- Double Submit Cookies:
-> Store cryptographically strong random value in a cookie
-> Site matching a token sent as a form value and compare it with the token in cookie
-> Due to the same origin policy, attacker can not modify the value in the cookie
3
Q
CSRF Mitigation
A
- Session time out after period of inactivity
- Confirmation of actions
- Client/User Side:
-> Logoff after using a web service
-> Do not save username/passwords in the browser
-> Use different browsers to access sensitive applications
-> Use Add-Ons like no-script to prevent POST based CSRF vulnerabilities to exploit
4
Q
Blind SQL Injection
A
- SQL can be injected without seeing the output
- Error-based blind SQL Injection: Abuse error messages to exfiltrate data
- Time-based: e.g. construct query that waits 1 second if a table starts with ‘A’
5
Q
Bad Session Management Countermeasures
A
- Always protect credentials through hashing/encryption (SSL/TLS)
- Credentials should not be guessed easily or overwritten through weak account management functions
- Never expose session IDs in the URL
- Users should have the possibility to log out
-> Sessions should timeout
-> Sessions should rotate
6
Q
Secure Passwords Recovery Mechanism
A
- Gather Identity Data
-> Ask User for multiple pieces of hard data
-> Minimum three inputs is recommended
-> Enhanced security: First ask the email address and send an email that takes users to a private page with other requests - Verify Security Questions
-> Verify all given answers
-> If incorrect, displays a generic error message
-> Avoid sending the username as a parameter when the form on this page is submitted (should be stored in server-side session) - Send a Token Out-of-Band
-> email or SMS the user a randomly generated code - Allow user to change password
7
Q
Sensitive Data Exposure Countermeasures
A
- Consider the threats you plan to protect this data from
- Ensure offsite backups are encrypted, but the keys are managed and backed up separately
- Ensure appropriate strong standard algorithms and strong keys are used and key management is in place
- Ensure passwords are hashed and salted with a strong standard algorithm
- Ensure all keys and passwords are protected from unauthorized access
8
Q
XML External Entities
A
- Vulnerable targets are applications that:
-> accept user XML input
-> don’t use restrict parser options - Entities define content with entity names that are shorter than the content, easier to type
9
Q
XML External Entities Countermeasures
A
- Use less complex data structures like JSON
- Disable external entities
- Whitelisting
10
Q
Broken Access Control Countermeasures
A
- Use per user or session indirect object references
- Check access control if user is authorized
- Deny all access by default
11
Q
Security Misconfiguration Countermeasures
A
- A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down
-> Development, test, and production environments should all be configured identically. This process should be automated to minimize the effort required to setup a new secure environment - A process deploying all new software updates and patches in a timely manner to each deployed environment. This needs to include all code libraries as well
- Consider running scans and audits periodically to help detect future misconfigurations or missing patches
12
Q
Non-persistant (reflected) XSS Vorgehen
A
- Attacker sends a prepared URL with JavaScript to the victim
- Opens malicious Web Application Site and executes JavaScript
- JavaScript sends secret information of the victim to the attacker
-> XSS is not saved in the web application
13
Q
Insecure Deserialization Countermeasures
A
- Don’t use serialization if not necessary
- Use minimal serialization e.g. CSV
- Sign strings or use MACs to prevent user modification
14
Q
Using Components with Known Vulnerabilities Countermeasures
A
- Identify all components and the versions you are using, including all dependencies
- Monitor the security of these components in public databases, project mailing list, and security mailing lists, and keep them up to date
- Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses
- Consider adding security wrappers around components to disable unused functionality and/or secure weak or vulnerable aspects of the component
15
Q
JavaScript Security Model
A
- Script runs in a “sandbox”
-> No direct file access, restricted network access - Same-origin-policy (SOP)
-> Can only read properties of documents and windows from the same server, protocol, and port
-> does not apply to script tags inserted into the site
