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

Update page 'OWASP test questions_Karen'

Karenzz
2023-05-26 18:50:15 +02:00
parent 0209f7e473
commit 0cdfeb630d
1 changed files with 148 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWASP test questions_Karen.md
+148 -36
@@ -4,45 +4,47 @@ https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
​ ​
* What is the principle of least privilege? * 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.* > *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. * 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.* > *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. * 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.* > * Failed login tracking: maintain a database that records failed login attempts, storing key information such as the username, timestamp, incoming IP address.
* *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.* > * *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.*
* *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.* > * *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.*
* *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.* > * *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.*
* *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.* > * *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.*
* *Alerting administrators: when suspicious activity surpasses a defined threshold or matches specific criteria, generate alerts or notifications to inform administrators or security personnel.* > * *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.*
* *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).* > * *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. * 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-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:* > * *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.* > * *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 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.* > * *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.* > * *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.* > * *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.* > * *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.* > * *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. * 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.* > * *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.*
* *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.* > * *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.*
* *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.* > * *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.*
* *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.* > * *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.*
* *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.* > * *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.*
* *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.* > * *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== ==A02==
@@ -55,42 +57,101 @@ https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
​ ​
* Why is it important that session IDs be random, instead of sequentially assigned? * 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.* > *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.* > *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. * 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. > * Identify the pattern by observing the patterns of session IDs used in the target system.
* 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. > * Armed with the knowledge of the pattern, the attacker begins enumerating or guessing session IDs based on the observed pattern.
* 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. > * 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 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
* www.google.com: The connection of this site is encryped and autheticated using QUIC, X25519, and AES_128_GCM
> * www.google.com: The connection of this site is encryped and autheticated using QUIC, X25519, and AES_128_GCM
> * www.neverssl.com: This page is not secure
> * www.sayweee.com: The connection to this site is encrypted and authenticated using TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM.
* What is the currently recommended strength, in bits, for AES when used in a TLS server? * What is the currently recommended strength, in bits, for AES when used in a TLS server?
*The currently recommended strength for AES when used in a TLS server is 128 bits.* > *The currently recommended strength for AES when used in a TLS server is 128 bits.*
* Describe what an export-grade cipher is. Does this concept still apply in this day and age? Why or why not? * Describe what an export-grade cipher is. Does this concept still apply in this day and age? Why or why not?
*An export-grade cipher refers to a cryptographic algorithm that was intentionally weakened by design or limited in key size to comply with cryptographic export regulations that were prevalent in the late 20th century.* > An export-grade cipher is a cryptographic algorithm which was designed in the past to comply with encryption export regulations imposed by certain countries.
> Now it may not be applied because the restrictions on the export of strong encryption have significantly relaxed, and modern cryptographic standards promote the use of robust and secure algorithms worldwide such as AES.
* Describe the circumstances under which any web browser released after 2020 would accept a SHA-1 signed TLS certificate, if any. * Describe the circumstances under which any web browser released after 2020 would accept a SHA-1 signed TLS certificate, if any.
> * Web brosers may accept SHA-1 signed certificates as they have not migrated to stronger hash algorithms, especially for those used in the internal and legacy systems. However, this situation is temporary as organizations will update their system to use stronger algorithms in a short future.
> * Certain certificates issued by specific Certificate Authorities (CAs) or for specific purposes may be exempted from the general deprecation of SHA-1. This exemption may be granted for a limited time and for specific domains or use cases.
* Is an extended validation TLS certificate more cryptographically secure than a normally issued TLS certificate? * Is an extended validation TLS certificate more cryptographically secure than a normally issued TLS certificate?
> No, an Extended Validation (EV) TLS certificate is not more cryptographically secure than a normally issued TLS certificate. The level of cryptographic security provided by a TLS certificate primarily depends on the strength of the underlying cryptographic algorithms and protocols used, such as the encryption algorithm and the hashing algorithm (for example, SHA-256).
* What is Let's Encrypt, and what incident caused the project to be founded? * What is Let's Encrypt, and what incident caused the project to be founded?
> Let's Encrypt is a non-profit certificate authority that provides free SSL/TLS certificates to enable secure communication on the web.
> The incident that led to the founding of Let's Encrypt was the revelation of pervasive surveillance and privacy concerns highlighted by the Edward Snowden disclosures in 2013. The disclosures shed light on the mass surveillance programs conducted by government agencies, which raised awareness about the importance of secure and private communication on the internet.
* What is a rainbow table? * What is a rainbow table?
> It's a precomputed table that contains a large number of potential plaintext-password pairs for different cryptographic hash functions, which is used as a time-memory trade-off technique to quickly reverse or crack password hashes.
* What is a cryptographic salt? * What is a cryptographic salt?
> A cryptographic salt is made up of random bits added to each password instance before its hashihng.
* What is a cryptographic pepper? * What is a cryptographic pepper?
> A pepper is a secret value added to a password before hashing.
* 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. * 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.
> First generate a random cryptographic pepper value.
> Store the pepper securely on each web server, ensuring it is protected from unauthorized access.
> Implement peppered hashing by combining the pepper with user passwords before applying the cryptographic hash function.
> Ensure that all web servers use the same pepper value for consistency.
> Safeguard the pepper during database backups by encrypting or securely storing the backup files.
> Limit access to the pepper to trusted personnel only, following appropriate access control measures.
> Regularly review and update the pepper if necessary to maintain security.
* 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. * 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.
> * Argon2: recommended iterations value can be high (maybe 10 or more) to increase the computational cost.
> * bcrypt: recommended work factor value usually should be between 10 and 14, which determines the computational cost and hashing time.
> * scrypt: CPU/Memory cost parameters depend on the desired security level and available resources.
* 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. * 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.
> The circumstances described here are not common, but it may appear when there are legal or regulatory obligations that require organizations to provide decrypted access to user credentials to law enforcement agencies under specific situations. Another special circustances may be the incident investigation, as system administrators may need to analyze the compromised credential store to determine the scope of the incident.
* Can you trust a database administrator with private customer data, ever? * Can you trust a database administrator with private customer data, ever?
> No. there is always a risk when granting access to sensitive customer data, no matter how trustworthiness of a database administrator can get based on his or her track record.
* 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 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?
> No. I mean trusting someone solely based on the threat of severe punishment is not a comprehensive or practical approach to data security. While severe consequences may act as a deterrent, they do not guarantee the prevention of data breaches or guarantee the administrator's trustworthiness.
* 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? * 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?
> No. Please don't trust me. I can't gurantee that I will try to keey the data security if there is someone gives me an offer with much more benefits that can be obtained far outweigh the possible penalties.
* Can the *customer* ever be trusted with their own private customer data? * Can the *customer* ever be trusted with their own private customer data?
> I think it depends on various factors including the customer's understanding of data security and their commitment to protecting their own data. However, to be honestly, I don't think customer can ever be trusted with their own private data as not all customers will have the same level of understanding or commitment to data security.
* Can *anyone* ever be trusted with private customer data? * Can *anyone* ever be trusted with private customer data?
> Based on the questions above and the discussion we made in yesterday's meeting, my answer to this one is no.
​ ​
==A03== ==A03==
​ ​
@@ -99,17 +160,68 @@ https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.
https://cwe.mitre.org/data/definitions/79.html https://cwe.mitre.org/data/definitions/79.html
​ ​
* What is little bobby tables? * What is little bobby tables?
> It is a humorous and memorable way to illustrate the potential consequences of failing to properly handle user input and the importance of input validation and sanitization in preventing SQL injection vulnerabilities.
* Describe the most insecure possible way to use an ORM to look up data in a table, using search parameters provided by the user. * Describe the most insecure possible way to use an ORM to look up data in a table, using search parameters provided by the user.
> It should be a condition which dirctly embed user-provided values into the query without any validation or sanitization.
* What is log4shell? What was the original intent of the exploited feature? Describe the exploit. * What is log4shell? What was the original intent of the exploited feature? Describe the exploit.
> Log4shell is a critical vulnerability that affects the popular Apache Log4j library. The original intent of the exploited feature was to provide the ability to dynamically insert values into log messages. It allowed developers to include placeholders in log messages, which would be replaced with the corresponding values at runtime.
> For example, a log message might include a placeholder for a user's name, and the actual name value would be inserted when the log message is generated.
* 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 a technique to debug a SQL injection payload, if the statement's success or failure, and database output, cannot be seen by the attacker.
> Attackers may employ techniques like time-based blind SQL injection to gather information indirectly. Time-based attacks involve injecting SQL statements that introduce artificial delays in the application's response, allowing the attacker to infer the success or failure of the injected payload.
* Describe how to prevent that technique. * Describe how to prevent that technique.
> * Implement robust input validation and sanitization techniques to ensure that user-provided data is properly validated and sanitized before being used in SQL queries. Use parameterized queries or prepared statements to separate data from SQL commands.
> * Restrict access to sensitive database operations and limit access to the database schema.
> * Employ a WAF that includes SQL injection protection mechanisms. WAFs can detect and block known SQL injection patterns and suspicious behavior.
* Why is it important to have an administrative front-end to manage the production database, as opposed to using the SQL console directly? * Why is it important to have an administrative front-end to manage the production database, as opposed to using the SQL console directly?
> It can provide a user-friendly interfact that simplifies the management tasks associated with the production database, and a well-designed administrative front-end can incorporate security measures.
* How could you tell if a XPath query you found is vulnerable to an injection attack? * How could you tell if a XPath query you found is vulnerable to an injection attack?
> Maybe I can apply XPath Injection testing by injecting specific payloads and observing the behavior of the application's response.
* What is a HTML entity? * What is a HTML entity?
> HTML entities are the reserved characters that are used in the HTML document.
* Describe an XSS vulnerability, and the most common way to defend against it. * Describe an XSS vulnerability, and the most common way to defend against it.
> An XSS vulnerability is a type of security vulnerability found in web applications that allows an attacker to inject malicious scripts into web pages viewed by other users. The injected scripts are executed in the context of the victim's browser, enabling the attacker to steal sensitive information, perform actions on behalf of the victim, or deface the website. The most common way to defend against XSS vulnerabilities is to implement proper input validation and output encoding.
* Why is a left angle bracket (`<`) important in that context? * Why is a left angle bracket (`<`) important in that context?
> The left angle bracket (<) is important because it is a special character used to denote the beginning of an HTML tag. If not properly handled or encoded, an unescaped left angle bracket can be interpreted by the browser as the start of an HTML tag, potentially allowing an attacker to inject malicious code.
* What is UTF-7? * What is UTF-7?
> UTF-7 is an obsolete variable-length character encoding for representing Unicode text using a stream of ASCII characters.
* Describe how to use UTF-7 to output a left angle bracket, without using a left angle bracket in your solution. * Describe how to use UTF-7 to output a left angle bracket, without using a left angle bracket in your solution.
> Start with the string you want to encode, which is < in this case. Then convert the string to UTF-16 encoding. Lastly, convert each UTF-16 character into its corresponding UTF-7 representation.
* List three things to look for in an input sanitizer to avoid XSS problems. * List three things to look for in an input sanitizer to avoid XSS problems.
> * Proper handling of special characters, such as "<" we have discussed above.
> * Look for an input sanitizer that effectively filters and sanitizes HTML tags and attributes. It should allow only safe tags and attributes to be included in the output while removing or neutralizing potentially dangerous ones.
> * The input sanitizer should have contextual awareness to differentiate between different types of data and the context in which it will be used.
> * Choose a well-maintained and regularly updated input sanitizer library or solution.
​ ​
​ ​