diff --git a/OWASP test questions_Karen.md b/OWASP test questions_Karen.md new file mode 100644 index 0000000..f9cd139 --- /dev/null +++ b/OWASP test questions_Karen.md @@ -0,0 +1,110 @@ +==A01== +​ +https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +​ +* What is the principle of least privilege? + +*Least privilege refers to the principle of assigning users only the minimum privileges necessary to complete their job.* + +* Look up and describe the same-origin security policy, from the perspective of someone writing a web front-end. + +*The same-origin security policy aims to protect users from malicious attacks and unauthorized data access, which is enforced by web browsers and restricts how documents or scripts in one origin can interact with resources from a different origin. As for someone writing a web front-end, it is essential to consider the same-origin security policy to build secure applications, including the same-origin restriction, security boundary, and cross-origin communication. For example, resources loaded from one origin can only interact with resources in the same origin, and a security boundary should be built to prevent malicious websites from accessing sensitive data such as cookies or local storage belonging to a different origin.* + +* Describe some logic to monitor failed logins, and using geolocation of the incoming IP address, the permissions of the username trying to log in, and the number of previously failed logins, a procedure to determine whether to alert administrators to a genuine break-in attempt vs a brute-force attempt. + * Failed login tracking: maintain a database that records failed login attempts, storing key information such as the username, timestamp, incoming IP address. + * *IP geolocation: utilize an IP geolocation service to determine the physical location of the IP address used for this login attempt. This information can help identify if the login is originating from a suspicious or unexpected location.* + * *User permissions: assign different permission levels to user accounts based on their roles or access privileges. Categorize accounts into groups such as regular users, administrators, or privileged accounts.* + * *Thresholds for failed logins and pattern analysis: set configurable thresholds for the number of allowed failed login attempts before taking further action, and look for repeated attempts from the same IP address. This step is set to protect the account and the number of allowed failed login attempts should depends on the different account group. For instance, administrators and privileged accounts may have lower threshold than the regular users.* + * *Suspicious activity detection: evaluate the failed login patterns against predefined rules to identify suspicious activity. Consider factors such as the number of failed logins within a specific time window, consecutive failed attempts, or a sudden increase in failed logins from different IP addresses.* + * *Differentiating genuine break-in vs. brute force: to differentiate between genuine break-in attempts and brute-force attempts, consider additional factors such as the user's history, account behavior, and the type of resources being accessed. For example, if an account with limited permissions is repeatedly targeted with numerous failed login attempts from various locations, it might indicate a brute-force attack.* + * *Alerting administrators: when suspicious activity surpasses a defined threshold or matches specific criteria, generate alerts or notifications to inform administrators or security personnel.* + * *Response actions: based on the severity of the detected activity, administrators can take appropriate response actions. These may include temporarily locking or disabling affected user accounts (this usually happen when failed logins occur several time up to the threshold), implementing additional security measures like two-factor authentication (like what happens when we want to send money by Zelle to someone new), or escalating the incident to the security team for further investigation (hope this never happens to me).* + + +* Describe the lifetime of a session-only cookie, and how this could be used to create a session authorization token. + +*A session-only cookie is a type of cookie that is stored in the user's browser memory and is automatically deleted once the user closed the browser session. The lifetime of it is tied to the user's browsing session.* +* *A session authotization token can be created by the following steps:* + * *User Authentication: When a user logs in to a web application, their credentials are verified by the server. If the credentials are valid, the server generates a unique session ID or token for that user.* + * *Session ID Storage: The server associates the session ID with the user's authenticated session and stores it in a server-side session store or database. This session ID serves as a reference to identify the user's session.* + * *Session ID Storage: The server associates the session ID with the user's authenticated session and stores it in a server-side session store or database. This session ID serves as a reference to identify the user's session.* + * *Session ID in a Cookie: The server sends the session ID as a session-only cookie in the HTTP response headers. The cookie is set with the "Set-Cookie" header, specifying the session ID and other optional attributes like the cookie name, domain, and path.* + * *Cookie Transmission: The user's browser receives the session-only cookie and stores it in memory. The browser automatically includes the cookie in subsequent HTTP requests to the same domain within the browsing session, ensuring that the session ID is sent back to the server with each request.* + * *Server-Side Validation: When the server receives an incoming request, it checks for the presence and validity of the session ID in the session-only cookie. It verifies whether the session ID matches an active session in the server-side session store.* + * *Authorized Access: If the session ID is valid and corresponds to an active session, the server grants the requested access, considering the user authenticated and authorized for the specific resources or actions associated with their session.* + * *Session Expiration: As the session-only cookie's lifetime is tied to the user's browsing session, the cookie and the associated session ID are automatically deleted from the user's browser memory when they close the browser or end the session.* + + +* Describe the logic the web server should use when being presented with a session authorization token from a user, which isn't in the server's corresponding database. + * *Token Validation: The web server first verifies the format and integrity of the session authorization token. It checks for any obvious issues like token format mismatch, tampering, or expiration.* + * *Invalid Token Response: If the token is determined to be invalid or tampered with, the server should respond with an appropriate error message, indicating that the token is unauthorized or has expired. This response can include an HTTP status code such as 401 Unauthorized or 403 Forbidden.* + * *Session Cleanup: As the token is invalid, the server should also take the necessary steps to clean up any remnants of the session on the server-side. This may involve removing the session record, clearing associated data, or performing any necessary security measures.* + * *User Notification: It can be helpful to provide the user with a clear and user-friendly error message explaining that their session has expired or is invalid. This message should guide them to reauthenticate, initiate a new session, or take appropriate actions based on the application's requirements.* + * *Logging and Security Monitoring: It is important to log and track unauthorized or unknown session authorization tokens. By maintaining detailed logs, the server administrators or security personnel can analyze the patterns, investigate any potential security incidents, and take preventive measures to protect against unauthorized access attempts.* + * *Preventing Token Enumeration: To avoid exposing sensitive information or enabling token enumeration attacks, the server should respond with generic error messages rather than disclosing specific details about the token validity or the reason for the rejection. This helps prevent attackers from gaining insights into the system's authentication mechanisms.* + * *Additional Security Measures: Consider implementing additional security measures such as rate limiting, IP blocking, or multi-factor authentication (MFA) to enhance the system's resilience against unauthorized access attempts and potential attacks.* + +​ +==A02== +​ +https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html +​ +https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +​ +https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html +​ +* Why is it important that session IDs be random, instead of sequentially assigned? + +The first two reasons should be the security and privacy. To be more specific, random session IDs provide a higher level of security compared to sequential IDs. Sequentially assigned session IDs are predictable and easier to guess or enumerate. Attackers could potentially guess or brute-force sequential session IDs, gaining unauthorized access to other users' sessions. Furthermore, sequential session IDs may inadvertently reveal information about the system's usage patterns, such as the number of active sessions or the rate at which sessions are created. This information can be useful for attackers in planning and executing attacks. +There are also some other reasons, such as the session ID length as sequential session IDs often have a limited and fixed length and increment by a predictable amount which can make it easier for attackers to perform session ID guessing attacks, while randome seesion IDs can have a larger range and a variable length. + +* Describe a way to attack a system which uses predictable session IDs. + * Identify the pattern by observing the patterns of session IDs used in the target system. + * Armed with the knowledge of the pattern, the attacker begins enumerating or guessing session IDs based on the observed pattern. + * If the pattern or algorithm used to generate session IDs is not immediately apparent, the attacker may resort to brute-forcing session IDs by systematically attempting a large number of possible combinations until a valid session ID is discovered. + * Once the attacker successfully guesses or discovers a valid session ID, they can use it to impersonate the legitimate user associated with that session. They can then gain unauthorized access to the user's account, sensitive data, or perform malicious actions on their behalf. + + +* What symmetric and non-symmetric ciphers does your browser use when connecting to the following web sites: www.google.com www.neverssl.com www.sayweee.com + + + + +* What is the currently recommended strength, in bits, for AES when used in a TLS server? +* Describe what an export-grade cipher is. Does this concept still apply in this day and age? Why or why not? +* Describe the circumstances under which any web browser released after 2020 would accept a SHA-1 signed TLS certificate, if any. +* Is an extended validation TLS certificate more cryptographically secure than a normally issued TLS certificate? +* What is Let's Encrypt, and what incident caused the project to be founded? +* What is a rainbow table? +* What is a cryptographic salt? +* What is a cryptographic pepper? +* Describe how to store and manage a cryptographic pepper in the context of multiple web servers sharing the same database, and backups. You may assume the web servers and backups are managed by trusted personnel. +* Name 3 password hash functions considered to be secure at the time you answer this question, and appropriate parameters for each when used to store user credentials in a secure database. +* Describe the circumstances under which a properly managed credential storage system would allow a system administrator to recover the unencrypted/unhashed credentials with an offline copy of the credential store. +* Can you trust a database administrator with private customer data, ever? +* If the database administrator will be immediately executed by firing squad if private customer data ever leaks, then can you trust them with the private customer data? +* If *you* will be immediately executed by firing squad if private customer data ever leaks, then can anyone ever trust *you* with the private customer data? +* Can the *customer* ever be trusted with their own private customer data? +* Can *anyone* ever be trusted with private customer data? +​ +==A03== +​ +https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +​ +https://cwe.mitre.org/data/definitions/79.html +​ +* What is little bobby tables? +* Describe the most insecure possible way to use an ORM to look up data in a table, using search parameters provided by the user. +* What is log4shell? What was the original intent of the exploited feature? Describe the exploit. +* Describe a technique to debug a SQL injection payload, if the statement's success or failure, and database output, cannot be seen by the attacker. +* Describe how to prevent that technique. +* Why is it important to have an administrative front-end to manage the production database, as opposed to using the SQL console directly? +* How could you tell if a XPath query you found is vulnerable to an injection attack? +* What is a HTML entity? +* Describe an XSS vulnerability, and the most common way to defend against it. +* Why is a left angle bracket (`<`) important in that context? +* What is UTF-7? +* Describe how to use UTF-7 to output a left angle bracket, without using a left angle bracket in your solution. +* List three things to look for in an input sanitizer to avoid XSS problems. +​ +​ \ No newline at end of file