==A01==
- What is the principle of least privilege?
The principle of least privilege (PoLP) is a computer security concept in which a user is given the minimum levels of access necessary to perform his or her job functions. The objective is to prevent users from accessing data or commands that do not pertain to their role, thereby mitigating the potential damage caused by human errors or malicious actions.
- Look up and describe the same-origin security policy, from the perspective of someone writing a web front-end.
The Same-Origin Policy (SOP) is a critical security concept in web development. It allows a web page's scripts to interact with resources from the same origin – that is, the combination of protocol (like http:// or https://), domain, and port must match. This helps to isolate websites from each other, protecting against potential security threats like Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS). As a web developer, one must always consider the SOP when making requests to different origins, and use techniques such as CORS (Cross-Origin Resource Sharing) when you want to allow controlled access across origins.
- 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.
- Monitor each login attempt, successful or not. > * If a login attempt fails:
> Record the IP address, timestamp, and username.
> crease the count of failed attempts for this IP address and/or username.
> * If there are more than a certain number of failed attempts in a certain timeframe from the same IP or username:
> Use a geolocation service to identify the location of the IP.
> Compare this location to the known or expected location of the user.
> Check the user's permission level. Higher-risk users (like admins) may warrant tighter security measures.
> * 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.
- 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?
It doesn't alter the best practices in data security. It remains that sensitive data should be encrypted, and access should be controlled and monitored, regardless of potential consequences. Trust should not be based on fear but on effective security measures.
- 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?
Trust should not be established through severe consequences or personal liability alone. Instead, it should be based on the implementation of robust security measures, regular audits, training, and a culture of privacy and security.
- Can the customer ever be trusted with their own private customer data?
In general, customers should have control over their own data, including the right to access it. However, they may not always follow best practices for data security, such as using strong passwords or safeguarding sensitive information. Therefore, systems should be designed to encourage and facilitate good security practices.
- Can anyone ever be trusted with private customer data?
Trust with private customer data should be established through robust security measures, ethical data handling practices, and transparency. These measures include data encryption, minimal data collection, secure storage, and strict access controls. It's not about whether anyone can be trusted, but rather about how systems and practices are designed to protect the data.
==A03==
- What is little bobby tables?
"Little Bobby Tables" refers to a humorous example from the webcomic "xkcd". In one strip, a character named Mrs. Roberts tells her son's school that she named her son Robert'); DROP TABLE Students;-- to demonstrate the dangers of not sanitizing user input in a SQL query, leading to SQL injection.
- Describe the most insecure possible way to use an ORM to look up data in a table, using search parameters provided by the user.
The most insecure way to use an ORM would be to directly concatenate user-supplied input into a query without any validation or sanitization. This approach makes the application susceptible to SQL Injection attacks.
- What is log4shell? What was the original intent of the exploited feature? Describe the exploit.
Log4Shell is a severe vulnerability (CVE-2021-44228) in the Log4j logging library, a widely-used Java-based logging utility. The vulnerability allows for arbitrary code execution through a flaw in the way Log4j handles log messages. The original intent of the exploited feature was to provide a way to perform logging in a variety of contexts, and to provide lookup functionality to include additional information in log messages. The exploit involves using this lookup functionality in an unintended way. Log4j is able to interpret log messages that contain references to external resources, specifically LDAP servers. A specially crafted log message can force Log4j to load malicious code from an external LDAP server controlled by the attacker. This code is then executed within the context of the running Java application, potentially leading to a full system compromise. This vulnerability became infamous due to its severity, the simplicity of exploitation, and the widespread use of the affected library. It was rated with a CVSS score of 10, indicating the highest level of severity.
- 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.
One common technique for blind SQL injection is to use a method known as time-based SQL injection. Here, the attacker can send SQL queries that cause the database to wait for a specified amount of time before responding. By measuring the response times, an attacker can infer if the SQL query was successful.
- Describe how to prevent that technique.
To prevent time-based SQL injection, we should follow the general prevention techniques for SQL Injection. This includes using parameterized queries, ORM, or stored procedures to interact with the database and avoid the inclusion of user-supplied input directly into SQL queries. Also, limit the privileges of database accounts used by web applications.
- Why is it important to have an administrative front-end to manage the production database, as opposed to using the SQL console directly?
Having an administrative front-end allows for a more controlled and secure way to interact with the database. It can provide user-friendly interfaces, limit the execution of potentially harmful commands, log activities for audit purposes, and manage access controls.
- How could you tell if a XPath query you found is vulnerable to an injection attack?
XPath Injection vulnerabilities typically occur when a web site uses user-supplied information to construct an XPath query for XML data. If we can provide input that changes the structure of the query itself, or see that user input is inserted into queries without being sanitized, then the XPath query is likely vulnerable to an injection attack.
- What is a HTML entity?
An HTML entity is a piece of text ("string") that begins with an ampersand (&) and ends with a semicolon (;). Entities are used to represent reserved characters in HTML that can't be used as they may be confused with HTML markup.
- Describe an XSS vulnerability, and the most common way to defend against it.
Cross-Site Scripting (XSS) vulnerabilities occur when an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. The most common way to defend against XSS is by using context-sensitive output encoding/escaping techniques when inserting user-supplied content into the page.
- Why is a left angle bracket (
<) important in that context?
The left angle bracket (<) signifies the start of a tag in HTML. If an attacker can inject a string containing a left angle bracket, they might be able to start a new HTML or script tag, leading to a potential XSS attack.
- What is UTF-7?
UTF-7 is a way of encoding Unicode characters using only a subset of ASCII characters. It was created for use in email systems, which did not originally support non-ASCII characters.
- Describe how to use UTF-7 to output a left angle bracket, without using a left angle bracket in your solution.
In UTF-7, the left angle bracket (<) can be represented as "+ADw-". Note that this can contribute to XSS vulnerabilities if a web application's content-type can be changed or the charset is not specified and the browser interprets the charset as UTF-7.
- List three things to look for in an input sanitizer to avoid XSS problems.
Input sanitizers should: > * Be context-aware: Different contexts (like HTML, URLs, CSS, or JavaScript) have different rules about what characters are dangerous. > * Encode or remove special characters: Characters like <, >, ", ', and & often need to be encoded depending on context. > * Be regularly updated and maintained: New attack techniques are discovered regularly, and a good sanitizer library will keep up with these techniques.