SVIG/python-bootcamp
7
0
Fork 1
Code Issues Pull Requests 1 Releases Wiki Activity

Update page 'OWASP test - Sloetjes'

xuanyi.wang
2023-05-25 17:20:36 +02:00
parent 19656179b0
commit 2b36cc120e
1 changed files with 43 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWASP test - Sloetjes.md
+43
@@ -18,26 +18,69 @@
> If the location doesn't match or there are too many attempts, it may be a brute force or break-in attempt. Notify the administrators based on these factors.
* Describe the lifetime of a session-only cookie, and how this could be used to create a session authorization token.
> Session-only cookies, also known as transient cookies, exist only in the temporary memory of the browser and are deleted when the user closes their browser. This means the lifespan of a session-only cookie is tied directly to the duration of the browsing session. These cookies can be used to create a session authorization token, which represents the user's session. This token can be used to maintain the state of the session and to track the user's activities during the session, making it easier to manage user authorization and access controls.
* 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.
> When the server receives a session authorization token, it should first look up the token in its session database. If the token does not exist, the server should consider this as an invalid or expired session.
> On receiving a session token from a client, search for the token in the session database.
> If not found:
> Return an authentication error (typically HTTP 401 Unauthorized).
> Prompt the user to log in again to create a new valid session.
> If the token is found, validate it to ensure it has not expired and is associated with the user’s current session.
> Continue to serve the requested resources if the token is valid and has appropriate privileges.
> The server should also take note of frequent invalid session token attempts, as these could signify a potential security threat such as session hijacking or token guessing attempts.
==A02==
* Why is it important that session IDs be random, instead of sequentially assigned?
> Session IDs need to be random and unpredictable to prevent session prediction attacks. If they are assigned sequentially, an attacker might be able to predict the session ID of another user, thereby hijacking their session. This would allow the attacker to impersonate the user and potentially gain unauthorized access to sensitive information.
* Describe a way to attack a system which uses predictable session IDs.
> One way to attack a system with predictable session IDs is through a session prediction attack. Here, an attacker can analyze a set of session IDs, identify a pattern, and then predict future session IDs. Once the attacker successfully predicts a valid session ID, they can use it to impersonate a user, gaining unauthorized access to their session and data.
* 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?
> The current recommended key length for AES in a TLS server is 256 bits, commonly referred to as AES-256.
* Describe what an export-grade cipher is. Does this concept still apply in this day and age? Why or why not?
> Export-grade ciphers are cryptographic algorithms that were deliberately weakened so they could be exported from the United States under the country's export regulations during the 1990s. Today, this concept is mostly obsolete, as export restrictions on strong cryptography have been significantly relaxed. However, some older systems might still support these weak ciphers, which can lead to vulnerabilities such as the FREAK and Logjam attacks.
* Describe the circumstances under which any web browser released after 2020 would accept a SHA-1 signed TLS certificate, if any.
> After 2020, modern web browsers should not accept SHA-1 signed certificates, due to the known vulnerabilities of SHA-1. Some legacy systems might still accept them, but it's generally recommended to transition to more secure hashing algorithms like SHA-256.
* Is an extended validation TLS certificate more cryptographically secure than a normally issued TLS certificate?
> An Extended Validation (EV) certificate doesn't offer more cryptographic security than a typical TLS certificate. Both use the same encryption methods and strength. However, EV certificates involve a more rigorous verification process of the entity behind the website, thereby offering more assurance to users about the website's authenticity.
* What is Let's Encrypt, and what incident caused the project to be founded?
> Let's Encrypt is a free, automated, and open certificate authority that provides TLS certificates to websites. It was founded to help create a more secure and privacy-respecting web by encouraging widespread encryption. The project was not founded due to a specific incident, but rather as a broader response to the underutilization of HTTPS on the internet.
* What is a rainbow table?
> A rainbow table is a precomputed table used for reversing cryptographic hash functions. It's used to crack password hashes by looking up the hash in the table and finding the corresponding plaintext value. Rainbow tables make it faster to crack hashes but can be mitigated by using techniques like salting the hashes.
* What is a cryptographic salt?
> A cryptographic salt is random data that is used as an additional input to a hash function that hashes a password. The primary function of salts is to defend against dictionary attacks or against pre-computed rainbow table attacks by adding a degree of randomness and uniqueness to each hash.
* What is a cryptographic pepper?
> A cryptographic pepper is similar to a salt but instead of being stored alongside the password hash, it's stored separately or hardcoded in the application code. This adds an extra layer of security as even if the password hashes and salts are compromised, without the pepper, the hashes can't be cracked easily.
* 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.
> Peppers should be stored separately from the database, like in the application code or a separate configuration file. They should be securely managed and access should be limited only to trusted individuals. It's important that peppers are included in backups, but they should be stored separately from the data they protect to maintain their effectiveness.
* 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.
> As of my knowledge cutoff in September 2021, bcrypt, scrypt, and Argon2 are considered secure password hash functions.
> bcrypt: You can use a cost factor of 10-12, which determines the computational cost of the hash.
> scrypt: Parameters include CPU/memory cost factor, block size, and parallelization factor. Recommended values might be N=16384, r=8, p=1.
> Argon2: Recommended parameters vary depending on the specific use-case and threat model. The OWASP password storage cheat sheet doesn't provide specific recommendations but does mention Argon2 as a good choice.
* 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.
> In a properly managed credential storage system, it should not be possible to recover the original plaintext passwords from the stored hashed values, even if you have an offline copy of the credential store. If a system allows for this, it's a sign of poor security practices.
* Can you trust a database administrator with private customer data, ever?
> Trust in this context depends on the integrity of the individual and the safeguards in place. A database administrator should ideally not have the ability to view sensitive customer data in plaintext. Using proper encryption and access control measures can prevent unauthorized access, including by database administrators.
* 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?