Requirements:: Password Security

Control Name: Verify that user set passwords are at least 12 characters in length
(after multiple spaces are combined).

How to Validate: Use tools like Burp Suite or OWASP ZAP to intercept network
traffic and examine the request/response payloads to see how the password is being
transmitted and processed.

POC:

Here we can see that the HTTP response code is 302. That required the client to
perform a temporary redirect with the same method along with means redirects by
changing the method to GET. There is no password length policy. So, we can say that
the minimum password length isn’t 12.
________________
Control Name: Verify that passwords of at least 64 characters are permitted, and
that passwords of more than 128 characters are denied.

How to Validate: Use tools like Burp Suite or OWASP ZAP to intercept network
traffic and examine the request/response payloads to see how the password is being
transmitted and processed.

POC:

It accepts passwords whose lengths are more than or equal to 64.

It accepts passwords whose lengths are less than or equal to 127 and denied more
than or equal to 128.

Password length 127(request)

Password length 127(response)

So, the website accepts passwords whose lengths are less than or equal to 64 and
denies passwords more than or equal to 128.
________________
Control Name: Verify that password truncation is not performed. However,
consecutive multiple spaces may be replaced by a single space.

How to Validate: Use tools like Burp Suite or OWASP ZAP to intercept network
traffic and examine the request/response payloads to see how the password is being
transmitted and processed.

POC:

It counts all spaces. That means consecutive multiple spaces are not replaced by a
single space.
________________
Control Name: Verify that any printable Unicode character, including language
neutral characters such as spaces and Emojis are permitted in passwords.

How to Validate: Use tools like Burp Suite or OWASP ZAP to intercept network
traffic and examine the request/response payloads to see how the password is being
transmitted and processed.

POC:

There are no responses. So, it doesn’t accept all printable unicode.

________________
Requirements: General Authenticator Security

Control Name: Verify that anti-automation controls are effective at mitigating

breached credential testing, brute force, and account lockout attacks. Such
controls include blocking the most common breached passwords, soft lockouts, rate
limiting, CAPTCHA, ever increasing delays between attempts, IP address
restrictions, or risk-based restrictions such as location, first login on a device,
recent attempts to unlock the account, or similar. Verify that no more than 100
failed attempts per hour is possible on a single account.

How to Validate: Try to perform a brute force attack by continuously entering

incorrect passwords. Observing the behavior of the system, if it blocks the IP
address, increases the delay between attempts, or imposes a lockout after a certain
number of failed attempts, it indicates that the anti-automation controls are
working as expected.

POC:

It doesn’t block the failed attempts as the response code isn’t 404. So, it breaks
the control.
________________
Control Name: Verify that the use of weak authenticators (such as SMS and email) is
limited to secondary verification and transaction approval and not as a replacement
for more secure authentication methods. Verify that stronger methods are offered
before weak methods, users are aware of the risks, or that proper measures are in
place to limit the risks of account compromise.

How to Validate: Try to make more than 100 failed attempts in an hour on a single
account and observe if the system blocks the IP address or imposes a lockout. If
the system allows more than 100 failed attempts, it indicates that the anti-
automation controls need to be tightened.

POC:

It doesn’t block the failed attempts as the response code isn’t 404. So, it breaks
the control.
Requirements:: Fundamental Session Management Security

Control Name: Verify the application never reveals session tokens in URL
parameters.

How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp
Suite to monitor the network traffic between the client and the server. Attempt to
authenticate to the application using valid credentials.

POC:
It doesn’t reveal session tokens.
________________
Requirements: Session Binding

Control Name: Verify the application generates a new session token on user
authentication.

How to Validate: Check the server's response that the server responds with a new
session token after successful authentication by Wireshark or Burp suite. The
session token should be unique and not easily guessable.

POC:

Tokens and cookies are the same for two times of login. So, it breaks “Session
Management”.
________________

Control Name: Verify that session tokens possess at least 64 bits of entropy.

How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp
Suite to monitor the network traffic between the client and the server. Attempt to
authenticate to the application using valid credentials.

POC:
Tokens are 50 bits here that don't follow the 64 bits control.
________________
Control Name: Verify the application only stores session tokens in the browser
using secure methods such as appropriately secured cookies or HTML 5 session
storage.

How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp
Suite or Inspect to monitor the network traffic between the client and the server.
Attempt to authenticate to the application using valid credentials.

POC:

No local storage and session storage.

________________
Control Name: Verify that session tokens are generated using approved cryptographic
algorithms.

How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp
Suite to monitor the network traffic between the client and the server. Attempt to
authenticate to the application using valid credentials.

POC:

________________

Requirements: Session Termination

Control Name: Verify that logout and expiration invalidate the session token, such
that the back button or a downstream relying party does not resume an authenticated
session, including across relying parties.

How to Validate: Log out of the application and log back in to see if a new session
token is generated each time.
POC:

After logout from the site, I clicked the back button and then reloaded the site
and captured the burp request. After forwarding some requests, I get back the uname
and password. By forwarding it, I get access to the site.

So, it violates the logout control.

________________
Control Name: If authenticators permit users to remain logged in, verify that re-
authentication occurs periodically both when actively used or after an idle period.

How to Validate: Use Burp Suite to see the request token of logging in.

POC:

No re-authentication occurs. So, it breaks the control.

________________
Control Name: Verify that the application gives the option to terminate all other
active sessions after a successful password change (including change via password
reset/recovery), and that this is effective across the application, federated login
(if present), and any relying parties.

How to Validate: Use Burp Suite to see the response.

POC:

After changing, no alert happened.

________________

Control Name: Verify that users are able to view and (having re-entered login
credentials) log out of any or all currently active sessions and devices.

How to Validate: Use Burp Suite to see the response and request.

POC:

Decoded cookie as URL.

________________

Requirements: Cookie-based Session Management

Control Name: Verify that cookie-based session tokens have the 'Secure' attribute
set.

How to Validate: Use Burp Suite or Inspect option to navigate to the "Application"
or "Storage" tab in the developer tools. Find the section for Cookies and select
the website you want to inspect. Look for the cookie that represents the session
token and examine its attributes. Verify that the 'Secure' attribute is set to
'True'. This means that the cookie will only be transmitted over an encrypted
connection (HTTPS) and will not be sent over an unencrypted connection (HTTP). If
the 'Secure' attribute is not set, this means that the session token could be
intercepted by an attacker and used to hijack the user's session.

POC:

Secure attribute isn’t set.

________________

Control Name: Verify that cookie-based session tokens have the 'HttpOnly' attribute
set.

How to Validate: Use Burp Suite or Inspect option to navigate to the "Application"
or "Storage" tab in the developer tools. Find the section for Cookies and select
the website you want to inspect. Look for the cookie that represents the session
token and examine its attributes. Verify that the 'HTTP Only' attribute is set to
'True'. This means that the cookie will only be transmitted over an encrypted
connection (HTTPS) and will not be sent over an unencrypted connection (HTTP). If
the 'Secure' attribute is not set, this means that the session token could be
intercepted by an attacker and used to hijack the user's session.

POC:

HttpOnly isn’t set.

________________

Control Name: Verify that cookie-based session tokens utilize the 'SameSite'
attribute to limit exposure to cross-site request forgery attacks.

How to Validate: Inspect the request and see the cookie-session.

POC:

The SameSite attribute isn’t set.

________________

Control Name: Verify that cookie-based session tokens use the "__Host-" prefix so
cookies are only sent to the host that initially set the cookie.

How to Validate: Inspect the request and see the cookie-session.

POC:

There is no HOST prefix in this site.

________________

Control Name: Verify that if the application is published under a domain name with
other applications that set or use session cookies that might disclose the session
cookies, set the path attribute in cookie-based session tokens using the most
precise path possible.

How to Validate: Inspect the request and see the cookie-session.

POC:
Path isn’t set as precise.
________________

Requirements: Token-based Session Management

Control Name: Verify the application allows users to revoke OAuth tokens that form
trust relationships with linked applications.

How to Validate: Use Burp Suite to see the session token generation using the Burp
Intruder, Sequencer and Decoder tools.

POC:

A general cookie setter.

________________

Control Name: Verify the application uses session tokens rather than static API
secrets and keys, except with legacy implementations.

How to Validate: Use Inspect to see the cookie.

POC:

It uses a static cookie named “login=test%2Ftest”.

________________

Control Name: Verify that stateless session tokens use digital signatures,
encryption, and other countermeasures to protect against tampering, enveloping,
replay, null cipher, and key substitution attacks.

How to Validate: Use Inspect to see the cookie generation.

POC:
Always set as 3 which breaks the control.
________________

Requirements: Federated Re-authentication

Control Name: Verify that Relying Parties (RPs) specify the maximum authentication
time to Credential Service Providers (CSPs) and that CSPs re- authenticate the user
if they haven't used a session within that period.

How to Validate: Make sure that the maximum authentication time is specified in a
secure manner. Conduct a test to see how the authentication process works between
RPs and CSPs. Try to access a resource that requires authentication and observe how
the system behaves. Make sure that the re-authentication process is secure and that
the user's credentials are encrypted when transmitted. Check that the system logs
the re-authentication events properly. This will help the application owner to
track when re-authentication occurs and to identify any potential issues. Finally,
we have to test the system for security vulnerabilities related to authentication.
For example, trying to bypass the authentication process or manipulate the maximum
authentication time to see if we can access a resource without proper
authentication.

POC:

After logout from the site, I clicked the back button and then reloaded the site
and captured the burp request. After forwarding some requests, I get back the uname
and password. By forwarding it, I get access to the site. It doesn’t need any re-
authentication.
________________
Control Name: Verify that Credential Service Providers (CSPs) inform Relying
Parties (RPs) of the last authentication event, to allow RPs to determine if they
need to re-authenticate the user.

How to Validate: Starting by understanding how the authentication process works

between RPs and CSPs. Get a clear understanding of the flow of data between the two
parties. Next, we have to review the source code of the RPs and CSPs to look for
any references to a maximum authentication time. Make sure that the maximum
authentication time is specified in a secure manner.

POC:
After logout from the site, I clicked the back button and then reloaded the site
and captured the burp request. After forwarding some requests, I get back the uname
and password. By forwarding it, I get access to the site.

________________

Requirements: Defenses Against Session Management Exploits

Control Name: Verify the application ensures a full, valid login session or
requires re-authentication or secondary verification before allowing any sensitive
transactions or account modifications.

How to Validate: Try to log in to the application using valid credentials and
observe how the application handles the login process. Check if the application
implements proper authentication methods, such as password hashing and salting, to
secure the user's login information. Make sure that the application generates a new
session ID for each login and that it's properly tied to the user's account.

POC:

It doesn’t generate different cookies.

________________
Requirements:: General Access Control Design

Control Name 1: Verify that the application enforces access control rules on a
trusted service layer, especially if client-side access control is present and
could be bypassed.
Control Name 2: Verify that all user and data attributes and policy information
used by access controls cannot be manipulated by end users unless specifically
authorized.
Control Name 3: Verify that the principle of least privilege exists -users should
only be able to access functions, data files, URLs, controllers, services, and
other resources, for which they possess specific authorization. This implies
protection against spoofing and elevation of privilege.
Control Name 4: Verify that access controls fail securely including when an
exception occurs.
How to Validate: Start by testing the client-side access controls to see if they
can be bypassed. This can be done by modifying the client-side code or intercepting
the client-side communication to see if the access control rules can be
circumvented. After testing the client-side access controls, test the server-side
access controls to ensure that they are being enforced as expected. This can be
done by sending specially crafted requests to the server to see if the access
control rules are being applied correctly. Attempt to access resources and perform
actions that should not be allowed according to the access control rules. This can
help verify that the access control rules are being properly enforced and that
there are no gaps or weaknesses in the implementation. Ensure that the trusted
service layer is properly secured and that it is enforcing the access control rules
as expected. This could include verifying that the service layer is using
encryption and that it is properly authenticating requests.

POC:

Without login, it doesn’t give any access to the site to change anything. But we
can bypass the request using sql injections that are vulnerable to malicious code.
________________
Requirements: Operation Level Access Control

Control Name 1: Verify that sensitive data and APIs are protected against Insecure
Direct Object Reference (IDOR) attacks targeting creation, reading, updating and
deletion of records, such as creating or updating someone else's record, viewing
everyone's records, or deleting all records.
Control Name 2: Verify that the application or framework enforces a strong anti-
CSRF mechanism to protect authenticated functionality, and effective anti-
automation or anti-CSRF protects unauthenticated functionality.

How to Validate: Test the creation, reading, updating, and deletion of records in
the system to identify any IDOR vulnerabilities. This could include trying to
create or update records for other users, viewing records for all users, or
deleting all records. Check for direct object references in the system, such as
URLs or parameters that reference a specific record or object. Direct object
references can make it easier for an attacker to manipulate the data or perform
unauthorized actions. Ensure that access controls are in place to prevent
unauthorized access to sensitive data and APIs. This could include authentication,
authorization, and encryption. The access control logic is properly implemented and
that it is not broken. This could include checking for missing or incorrect access
control checks, or checking that the access control rules are properly enforced on
the server side. Monitor logs and audit trails for unusual or suspicious activity,
such as repeated attempts to access sensitive data or perform unauthorized actions.
This can help detect and prevent IDOR attacks.

POC:

Its attributes aren’t set properly, that's why it is vulnerable to IDOR attacks.
________________
Requirements: Other Access Control Considerations
Control Name 1: Verify administrative interfaces use appropriate multi-factor
authentication to prevent unauthorized use.
Control Name 2: Verify that directory browsing is disabled unless deliberately
desired. Additionally, applications should not allow discovery or disclosure of
file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
Control Name 3: Verify the application has additional authorization (such as step
up or adaptive authentication) for lower value systems, and / or segregation of
duties for high value applications to enforce anti-fraud controls as per the risk
of application and past fraud.

How to Validate: Start by testing the authentication mechanism used by the

administrative interface to ensure that it is properly implemented and secure. This
could include attempting to bypass the authentication mechanism, or testing the
strength of the passwords used. Ensure that the administrative interface uses
multi-factor authentication, such as something the user knows (a password),
something the user has (a smart card or token), and something the user has
(biometrics). Check for implementation weaknesses in the multi-factor
authentication mechanism, such as missing or weak security controls, or the use of
easily guessable or easily obtainable authentication factors. Test the
authentication process to ensure that it is working correctly and that the multi-
factor authentication is being used properly. This could include attempting to log
in with different combinations of authentication factors. Monitor logs and audit
trails for unusual or suspicious activity, such as repeated attempts to log in or
access the administrative interface. This can help detect and prevent unauthorized
access.

POC:

When I tried to login manually to this site, there were no two factor
authentication systems implemented.

________________

Requirements:: Input Validation

Control Name: Verify that the application has defenses against HTTP parameter
pollution attacks, particularly if the application framework makes no distinction
about the source of request parameters (GET, POST, cookies, headers, or environment
variables).

How to Validate: For manual testing, try to inject multiple parameters with the
same name, and observe the application's behavior. Also can use tools like Burp
Suite or OWASP ZAP to modify the parameters in a request and observe the response
from the application. If the application is vulnerable, it will likely use only the
last parameter provided, or concatenate the values of all parameters with the same
name. Use a web application vulnerability scanner to identify any potential HPP
vulnerabilities. Some scanners, such as OWASP ZAP, can automatically detect HPP
vulnerabilities and provide recommendations for remediation. Conduct a penetration
test to see if an attacker can exploit HPP vulnerabilities in the application. This
can be done manually or with automated tools.

POC:

Request-1

Request-2

Different behavior on different requests.

________________
Control Name 1: Verify that frameworks protect against mass parameter assignment
attacks, or that the application has countermeasures to protect against unsafe
parameter assignment, such as marking fields private or similar.
Control Name 2: Verify that all input (HTML form fields, REST requests, URL
parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using
positive validation (allow lists).
Control Name 3: Verify that structured data is strongly typed and validated against
a defined schema including allowed characters, length and pattern (e.g. credit card
numbers, e-mail addresses, telephone numbers, or validating that two related fields
are reasonable, such as checking that suburb and zip/postcode match).
Control Name 4: Verify that URL redirects and forwards only allow destinations
which appear on an allow list, or show a warning when redirecting to potentially
untrusted content.

How to Validate: After accessing the site inspect its cookies and http requests.

POC:

Path, Max-Age, httpOnly, Secure options aren’t defined properly. Indexed DB is also
empty here.
________________

Requirements:: Data Classification

Control Name 1: Verify that regulated private data is stored encrypted while at
rest, such as Personally Identifiable Information (PII), sensitive personal
information, or data assessed likely to be subject to EU's GDPR.
Control Name 2: Verify that regulated health data is stored encrypted while at
rest, such as medical records, medical device details, or de-anonymized research
records.
Control Name 3: Verify that regulated financial data is stored encrypted while at
rest, such as financial accounts, defaults or credit history, tax records, pay
history, beneficiaries, or de-anonymized market or research records.

How to Validate: The first step is to gain an understanding of the type and scope
of data that is considered private and regulated. For example, Personally
Identifiable Information (PII), sensitive personal information, or data assessed
likely to be subject to EU's General Data Protection Regulation (GDPR). It's
important to understand the company's data security policies and procedures,
including the encryption requirements for storing private data. This information
can usually be found in the company's security manual or in the data protection
policy. Review the source code of the application to verify that it implements
encryption for storing private data. The code should include the encryption
algorithm, key length, and mode of operation. Inspect the database schema and
verify that encrypted fields are defined for private data. Also, verify that the
encryption key is stored in a secure location, such as a hardware security module
(HSM) or a key management server. Define that the encryption is functioning as
intended by conducting tests on the application. Try to retrieve private data
without the encryption key and ensure that it is not readable. Regularly monitor
the logs to detect any attempts to access private data without proper
authorization. Ensure that alerts are configured to trigger in case of unauthorized
access.
________________
Requirements: Algorithm

Control Name: Verify that all cryptographic modules fail securely, and errors are
handled in a way that does not enable Padding Oracle attacks.

How to Validate: Test the application to see how it handles cryptographic errors.
Try to induce errors in the encryption/decryption process and observe how the
application behaves. This will help you determine if the error handling mechanisms
are adequate and prevent sensitive information from being exposed.

POC:

It exposes the errors in detail which can be attacked by attackers.

________________
Control Name 1: Verify that industry proven or government approved cryptographic
algorithms, modes, and libraries are used, instead of custom coded cryptography.
Control Name 2: Verify that encryption initialization vector, cipher configuration,
and block modes are configured securely using the latest advice.
Control Name 3: Verify that random number, encryption or hashing algorithms, key
lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any
time, to protect against cryptographic breaks.
Control Name 4: Verify that known insecure block modes (i.e. ECB, etc.), padding
modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES,
Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used
unless required for backwards compatibility.
Control Name 5: Verify that nonces, initialization vectors, and other single use
numbers must not be used more than once with a given encryption key. The method of
generation must be appropriate for the algorithm being used.
Control Name 6: Verify that encrypted data is authenticated via signatures,
authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an
unauthorized party.
Control Name 7: Verify that all cryptographic operations are constant-time, with no
'short-circuit' operations in comparisons, calculations, or returns, to avoid
leaking information.

How to Validate: Regularly monitor the logs to detect any unexpected or unusual
behavior. This will help you identify any issues with the cryptographic modules and
allow you to take appropriate action. Conduct a code review to understand how
cryptographic operations are implemented in the application. Look for instances
where operations may be performed differently based on the input, or where data may
be leaked through side-channel attacks such as timing or power analysis. Test the
application to see if all cryptographic operations are constant-time. This can be
done by comparing the execution time of the operations with different inputs and
verifying that they are consistent. Padding Oracle attacks are a common type of
attack on encryption systems. Verify that the application is not vulnerable to
Padding Oracle attacks by testing the padding and ciphertext to determine if any
information can be leaked through the error messages. We can use tools, like:
Bletchley, PadBuster, Padding Oracle Exploitation Tool (POET), Poracle, python-
padding oracle.

POC:

Source: OWASP
________________
Requirements: Secret Management

Control Name 1: Verify that a secrets management solution such as a key vault is
used to securely create, store, control access to and destroy secrets.
Control Name 2: Verify that key material is not exposed to the application but
instead uses an isolated security module like a vault for cryptographic operations.

How to Validate: Review the architecture of the secrets management solution to

ensure that it meets industry-standard security requirements and best practices,
such as using encryption, access control, and audit logging. Check the
documentation of the secrets management solution to verify that it includes
detailed information on how secrets are stored, encrypted, and accessed. Evaluate
the encryption used to protect secrets to ensure that it meets the required level
of security and uses an approved cryptographic algorithm. Test the disaster
recovery procedures for the secrets management solution to verify that secrets can
be recovered in the event of a disaster or data loss.

POC:
It doesn’t use a secret key.
________________
Requirements:: Log Content

Control Name: Verify that the application does not log credentials or payment
details. Session tokens should only be stored in logs in an irreversible, hashed
form.

How to Validate: Review the logs generated by the application to ensure that they
do not contain sensitive information. If you find any instances of sensitive
information in the logs, report this to the developers so that they can remove this
information and implement proper logging practices.

POC:

Session tokens are in hashed format.

________________
Control Name: Verify that the application logs security relevant events including
successful and failed authentication events, access control failures,
deserialization failures and input validation failures.

How to Validate: Review the logs generated by the application to ensure that they
do not contain sensitive information. If you find any instances of sensitive
information in the logs, report this to the developers so that they can remove this
information and implement proper logging practices.

POC:

It includes successful and failed authentication events in the response sector.

________________
Control Name: Verify that each log event includes necessary information that would
allow for a detailed investigation of the timeline when an event happens.

How to Validate: Review the logs generated by the application to ensure that they
do not contain sensitive information. If you find any instances of sensitive
information in the logs, report this to the developers so that they can remove this
information and implement proper logging practices.

POC:

Log event includes necessary information

________________
Requirements: Log Processing
Control Name 1: Verify that all authentication decisions are logged, without
storing sensitive session tokens or passwords. This should include requests with
relevant metadata needed for security investigations.
Control Name 2: Verify that all access control decisions can be logged and all
failed decisions are logged. This should include requests with relevant metadata
needed for security investigations.

How to Validate: Test the logging functionality of the application to ensure that
authentication decisions are being recorded accurately and securely. This can be
done by attempting to log in to the application with test credentials and
monitoring the logs to see if the authentication decisions are being recorded
correctly. Regularly monitor the logging process to ensure that authentication
decisions are being recorded accurately and securely and that sensitive information
is not being stored in the logs.

POC:

All tokens are logged.

________________
Requirements: Log Protection

Control Name 1: Verify that all logging components appropriately encode data to
prevent log injection.
Control Name 2: Verify that security logs are protected from unauthorized access
and modification.
Control Name 3: Verify that time sources are synchronized to the correct time and
time zone. Strongly consider logging only in UTC if systems are global to assist
with post-incident forensic analysis.

How to Validate: Thoroughly review the source code of the application to identify
all logging components and determine how data is being encoded before being logged.
Verify that the encoding methods being used to encode data before it is logged are
appropriate and secure. This may include methods such as Base64 encoding, URL
encoding, or HTML encoding. Test the encoding functionality of the logging
components to ensure that data is being encoded correctly and securely. This can be
done by attempting to inject malicious data into the logs and monitoring the logs
to see if the malicious data is being recorded correctly. Regularly monitor the
logging process to ensure that data is being encoded correctly and securely and
that log injection is being prevented.

POC:

It encoded the credentials as base64. I check the request on burp decoder.

________________
Requirements: Error Handling

Control Name: Verify that a generic message is shown when an unexpected or security
sensitive error occurs, potentially with a unique ID which support personnel can
use to investigate.

How to Validate: Test the error handling functionality of the application by

attempting to trigger unexpected or security-sensitive errors. This can be done by
attempting to access restricted resources, inputting invalid data, or attempting to
exploit vulnerabilities in the application. Observe the error messages generated by
the application when errors occur. Verify that a generic message is being displayed
that does not reveal sensitive information or details about the error. Verify that
a unique ID is being included in the error message that support personnel can use
to investigate the error. This ID should be unique for each error and should allow
support personnel to quickly identify and resolve the issue.

POC:

No error messages shown.

________________
Control Name 1: Verify that exception handling (or a functional equivalent) is used
across the codebase to account for expected and unexpected error conditions.
Control Name 2: Verify that a "last resort" error handler is defined which will
catch all unhandled exceptions.

How to Validate: Test the error handling functionality of the application by

attempting to trigger unexpected or security-sensitive errors. This can be done by
attempting to access restricted resources, inputting invalid data, or attempting to
exploit vulnerabilities in the application. Observe the error messages generated by
the application when errors occur. Verify that a generic message is being displayed
that does not reveal sensitive information or details about the error. Verify that
a unique ID is being included in the error message that support personnel can use
to investigate the error. This ID should be unique for each error and should allow
support personnel to quickly identify and resolve the issue.

POC:

There are no exception handling functions that's why these types of errors occur.
________________

Requirements:: General Data Protection

Control Name 1: Verify the application protects sensitive data from being cached in
server components such as load balancers and application caches.
Control Name 2: Verify that all cached or temporary copies of sensitive data stored
on the server are protected from unauthorized access or purged/invalidated after
the authorized user accesses the sensitive data.
Control Name 3: Verify the application minimizes the number of parameters in a
request, such as hidden fields, Ajax variables, cookies and header values.
Control Name 4 :Verify the application can detect and alert on abnormal numbers of
requests, such as by IP, user, total per hour or day, or whatever makes sense for
the application.
Control Name 5: Verify that regular backups of important data are performed and
that test restoration of data is performed.
Control Name 6: Verify that backups are stored securely to prevent data from being
stolen or corrupted.

How to Validate: Review the architecture and configuration of the server

components, including load balancers and application caches, to determine how
sensitive data is being stored and protected. Verify that the application is
protecting sensitive data from being cached in server components by reviewing the
source code and configuration files to ensure that sensitive data is being
encrypted, hashed, or otherwise protected before it is stored. Regularly monitor
the behavior of server components, such as load balancers and application caches,
to ensure that sensitive data is not being cached. Test the data protection
mechanisms of the application by attempting to access sensitive data from server
components such as load balancers and application caches, and verifying that the
data cannot be accessed. Evaluate the risk associated with storing sensitive data
in server components, such as load balancers and application caches, and determine
if additional protection mechanisms are necessary.

POC:

Session tokens.

I generated many test cases but it didn’t generate any alerts.

________________
Requirements: Client-side Data Protection

Control Name: Verify the application sets sufficient anti-caching headers so that
sensitive data is not cached in modern browsers.

How to Validate: Verify that the application is setting anti-caching headers that
are appropriate for the types of data being transmitted, such as the Cache-Control,
Pragma, and Expires headers.

POC:
This data isn't present there.
________________
Control Name: Verify that data stored in browser storage (such as localStorage,
sessionStorage, IndexedDB, or cookies) does not contain sensitive data.

How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp
Suite or Inspect to monitor the network traffic between the client and the server.
Attempt to authenticate to the application using valid credentials.

POC:

No local storage and session storage.

________________

Control Name: Verify that authenticated data is cleared from client storage, such
as the browser DOM, after the client or session is terminated.

How to Validate: Log out of the application and log back in to see if a new session
token is generated each time.

POC:

After logout from the site, I clicked the back button and then reloaded the site
and captured the burp request. After forwarding some requests, I get back the uname
and password. By forwarding it, I get access to the site.

So, it violates the control.

________________

Requirements: Sensitive Private Data

Control Name 1: Verify that sensitive data is sent to the server in the HTTP
message body or headers, and that query string parameters from any HTTP verb do not
contain sensitive data.
Control Name 2: Verify that users have a method to remove or export their data on
demand.
Control Name 3: Verify that users are provided clear language regarding collection
and use of supplied personal information and that users have provided opt-in
consent for the use of that data before it is used in any way.
Control Name 4: Verify that all sensitive data created and processed by the
application has been identified, and ensure that a policy is in place on how to
deal with sensitive data.
Control Name 5: Verify accessing sensitive data is audited (without logging the
sensitive data itself), if the data is collected under relevant data protection
directives or where logging of access is required.
Control Name 6: Verify that sensitive information contained in memory is
overwritten as soon as it is no longer required to mitigate memory dumping attacks,
using zeroes or random data.
Control Name 7: Verify that sensitive or private information that is required to be
encrypted, is encrypted using approved algorithms that provide both confidentiality
and integrity.
Control Name 8: Verify that sensitive personal information is subject to data
retention classification, such that old or out of date data is deleted
automatically, on a schedule, or as the situation requires.

How to Validate: Review the application code to determine how data is being
transmitted from the client to the server. Verify that sensitive data is being
transmitted in the HTTP message body or headers, and not as query string parameters
in the URL. Regularly monitor the data transmission from the client to the server
to ensure that sensitive data is not being transmitted as query string parameters
in the URL. Test the data transmission from the client to the server by attempting
to transmit sensitive data as query string parameters in the URL and verifying that
the data is not transmitted in this manner.

POC:

These POC are given in session termination and http Security part.
________________

Requirements:: Client Communication Security

Control Name 1: Verify that TLS is used for all client connectivity, and does not
fall back to insecure or unencrypted communications.
Control Name 2: Verify using up to date TLS testing tools that only strong cipher
suites are enabled, with the strongest cipher suites set as preferred.
Control Name 3: Verify that only the latest recommended versions of the TLS
protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS
protocol should be the preferred option.

How to Validate: Thoroughly review the source code of the application to identify
the network communication functions and determine how they are being secured.
Verify that the application is using TLS for all client connectivity by reviewing
the source code and checking the configuration files to ensure that the correct
protocol (e.g. TLS 1.2) is being used. Test the TLS functionality of the
application by attempting to intercept network communications and verifying that
the data being transmitted is encrypted. Regularly monitor the network
communication of the application to ensure that it is being encrypted using TLS and
that there is no fallback to insecure or unencrypted communications.

POC:

The Network response.

________________

Requirements: Server Communication Security

Control Name 1: Verify that connections to and from the server use trusted TLS
certificates. Where internally generated or self-signed certificates are used, the
server must be configured to only trust specific internal CAs and specific self-
signed certificates. All others should be rejected.
Control Name 2: Verify that encrypted communications such as TLS is used for all
inbound and outbound connections, including for management ports, monitoring,
authentication, API, or web service calls, database, cloud, serverless, mainframe,
external, and partner connections. The server must not fall back to insecure or
unencrypted protocols.
Control Name 3: Verify that all encrypted connections to external systems that
involve sensitive information or functions are authenticated.
Control Name 4: Verify that proper certification revocation, such as Online
Certificate Status Protocol (OCSP) Stapling, is enabled and configured.
Control Name 5: Verify that backend TLS connection failures are logged.

How to Validate: Review the certificate configuration of the server to determine

the types of certificates that are being used. Assure that the server is using
trusted TLS certificates by checking the certificate chain and checking the
certificate revocation list (CRL) or the online certificate status protocol (OCSP)
to ensure that the certificate is still valid. If the server is using internally
generated or self-signed certificates, verify that the server is configured to only
trust specific internal CAs and specific self-signed certificates. All others
should be rejected. Regularly monitor the certificate usage of the server to ensure
that the correct certificates are being used and that the certificate configuration
has not been modified. Test the certificate validation process by attempting to
connect to the server using a certificate that is not trusted and verifying that
the connection is rejected.

POC:

It generates different certificates (cookies) and has a time duration of the

certificates.
________________
Requirements:: Code Integrity

Control Name: Verify that a code analysis tool is in use that can detect
potentially malicious code, such as time functions, unsafe file operations and
network connections.

How to Validate: The first step is to determine which code analysis tool is being
used by the organization. This information can typically be found in the software
development documentation or by asking the relevant individuals within the
organization. We can test the tool's ability to detect malicious code by using a
sample code that contains known vulnerabilities. The code analysis tool should flag
these vulnerabilities and provide suggestions for how to remediate them. Run the
code analysis tool on a sample of the organization's codebase to see how effective
it is at detecting malicious code. If the tool is not detecting the types of
vulnerabilities you are concerned about, consider reaching out to the vendor for
support or exploring alternative code analysis tools.

POC:

There are no analyzing tools available that’s why we can inject malicious code.
________________
Requirements: Malicious Code Search

Control Name 1: Verify that the application source code and third party libraries
do not contain unauthorized phone home or data collection capabilities. Where such
functionality exists, obtain the user's permission for it to operate before
collecting any data.
Control Name 2: Verify that the application does not ask for unnecessary or
excessive permissions to privacy related features or sensors, such as contacts,
cameras, microphones, or location.
Control Name 3: Verify that the application source code and third party libraries
do not contain back doors, such as hard-coded or additional undocumented accounts
or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging,
insecure debugging features, or otherwise out of date, insecure, or hidden
functionality that could be used maliciously if discovered.
Control Name 4: Verify that the application source code and third party libraries
do not contain malicious code, such as salami attacks, logic bypasses, or logic
bombs.

How to Validate: Thoroughly review the source code of the application to identify
any functions that may be sending data to a remote server or collecting data from
the user's device. Look for instances of network connections, data storage, and
data transmission functions. Third-party libraries are often used to add
functionality to an application. These libraries may contain code that is sending
data to a remote server or collecting data from the user's device. Check the source
code of these libraries to ensure that they are not collecting data without the
user's permission. Use a network analysis tool to monitor the network traffic
generated by the application. This will allow you to see what data is being
transmitted and where it is being sent. If we find that the application or third-
party libraries are collecting data from the user, ensure that the user is aware of
this and has given their permission for the data to be collected. This can be done
by adding a prompt or notification to the application that informs the user about
the data collection and requests their consent.

POC:

Database is encoded.

________________

Requirements:: Business Logic Security

Control Name 1: Verify that the application will only process business logic flows
for the same user in sequential step order and without skipping steps.
Control Name 2: Verify that the application will only process business logic flows
with all steps being processed in realistic human time, i.e. transactions are not
submitted too quickly.
Control Name 3: Verify the application has appropriate limits for specific business
actions or transactions which are correctly enforced on a per user basis.
Control Name 4: Verify that the application has anti-automation controls to protect
against excessive calls such as mass data exfiltration, business logic requests,
file uploads or denial of service attacks.
Control Name 5: Verify the application has business logic limits or validation to
protect against likely business risks or threats, identified using threat modeling
or similar methodologies.
Control Name 6: Verify that the application does not suffer from "Time Of Check to
Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations.
Control Name 7: Verify that the application monitors for unusual events or activity
from a business logic perspective. For example, attempts to perform actions out of
order or actions which a normal user would never attempt.
Control Name 8: Verify that the application has configurable alerting when
automated attacks or unusual activity is detected.

How to Validate: By identifying the various business logic flows that the
application handles, such as user registration, password reset, or purchase
transactions. Study the flow of each process and understand the order in which the
steps are executed. This will help you determine if there are any steps that can be
skipped. Manually test each process by executing the steps in order and verifying
that the steps are executed correctly without any skipping. Modify the input data
in a way that would allow users to skip a step in the process. For example, if the
process requires you to enter a password, try entering a blank password or an
incorrect password. Also can use various monitoring tools and technologies to
capture and analyze the application's behavior and performance. This includes tools
like application performance management (APM) solutions, log analysis tools, and
intrusion detection systems (IDS).

POC:
Here I use “facebook.com” to validate the controls. I try to log in by a number
which has no access. Then I create an account and have access to the site. It
doesn’t skip any steps. And do not give the access without verifying anything. But,
it gives the error message specifically which may attract the hackers.
________________

Requirements:: File Upload

Control Name: Verify that the application will not accept large files that could
fill up storage or cause a denial of service.

How to Validate: Test the file upload mechanism by uploading files of varying
sizes, including large files, to see how the application handles them. Pay
attention to any error messages or notifications that are generated, and look for
any indication that the application is not able to handle large files gracefully.
Monitor system resources, such as memory and disk usage, when uploading large files
to see if they cause any adverse effects. Conduct a denial of service test to see
if the application is vulnerable to a large number of file uploads or a large file
upload. This can be done manually or with automated tools, such as a load testing
tool. Conduct a penetration test to see if an attacker can exploit any weaknesses
in the application's handling of file uploads. This can be done manually or with
automated tools.

POC:

It accepts a big file that contains various types of data.

________________

Control Name: Verify that the application checks compressed files (e.g. zip, gz,
docx, odt) against maximum allowed uncompressed size and against maximum number of
files before uncompressing the file.

How to Validate: Test the file upload mechanism by uploading files of varying
sizes, including large files, to see how the application handles them. Pay
attention to any error messages or notifications that are generated, and look for
any indication that the application is not able to handle large files gracefully.
Monitor system resources, such as memory and disk usage, when uploading large files
to see if they cause any adverse effects. Conduct a denial of service test to see
if the application is vulnerable to a large number of file uploads or a large file
upload. This can be done manually or with automated tools, such as a load testing
tool. Conduct a penetration test to see if an attacker can exploit any weaknesses
in the application's handling of file uploads. This can be done manually or with
automated tools. Here I used the site “https://www.docdroid.net/” for check.
POC:

It checks the file extension.

________________
Control Name: Verify that a file size quota and maximum number of files per user is
enforced to ensure that a single user cannot fill up the storage with too many
files, or excessively large files.

How to Validate: Test the file upload mechanism by uploading files of varying
sizes, including large files, to see how the application handles them. Pay
attention to any error messages or notifications that are generated, and look for
any indication that the application is not able to handle large files gracefully.
Monitor system resources, such as memory and disk usage, when uploading large files
to see if they cause any adverse effects. Conduct a denial of service test to see
if the application is vulnerable to a large number of file uploads or a large file
upload. This can be done manually or with automated tools, such as a load testing
tool. Conduct a penetration test to see if an attacker can exploit any weaknesses
in the application's handling of file uploads. This can be done manually or with
automated tools. Here I used the site “https://www.docdroid.net/” for check.

POC:

File size isn't explored by the site.

________________
Requirements: File Integrity

Control Name: Verify that files obtained from untrusted sources are validated to be
of expected type based on the file's content.

How to Validate: Test the URL API that is used to access files to see if it is
protecting against path traversal attacks. This can be done by attempting to access
files outside of the intended directory, such as by using "../" in the URL.

POC:

________________

Requirements: File Execution

Control Name: Verify that user-submitted filename metadata is not used directly by
system or framework filesystems and that a URL API is used to protect against path
traversal.

How to Validate: Test the URL API that is used to access files to see if it is
protecting against path traversal attacks. This can be done by attempting to access
files outside of the intended directory, such as by using "../" in the URL.

POC:

Here we can not be able to get the file by api traversal as “../”.
________________
Control Name: Verify that user-submitted filename metadata is validated or ignored
to prevent the disclosure, creation, updating or removal of local files (LFI).

How to Validate: Without proper input sanitizing, an attacker could easily modify
the input (as shown below) to manipulate the application into accessing
unauthorized files and directories from the host server using the “../” directive.
This is known as Directory (Path) Traversal. Here I use the website
“http://www.textfiles.com/hacking/”

“https://textfiles.com/hacking/?page=../../../../etc/passwd.txt”

POC:

[After requesting]

Didn’t accept the unauthorized file access request.

________________

Control Name: Verify that user-submitted filename metadata is validated or ignored

to prevent the disclosure or execution of remote files via Remote File Inclusion
(RFI) or Server-side Request Forgery (SSRF) attacks.

How to Validate: Without proper input sanitizing, an attacker could easily modify
the input (as shown below) to manipulate the application into accessing
unauthorized files and directories from the host server using the “../” directive.
This is known as Directory (Path) Traversal. Here I use the website
“http://www.textfiles.com/hacking/”.

POC:

Accept the unauthorized file access request.

________________
Control Name: Verify that the application protects against Reflective File Download
(RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL
parameter, the response Content-Type header should be set to text/plain, and the
Content-Disposition header should have a fixed filename.

How to Validate: Without proper input sanitizing, an attacker could easily modify
the input (as shown below) to manipulate the application into accessing
unauthorized files and directories from the host server using the “../” directive.
This is known as Directory (Path) Traversal. Here I use the website
“http://www.textfiles.com/hacking/”.

POC:

File type isn’t defined.

________________
Control Name: Verify that untrusted file metadata is not used directly with system
API or libraries, to protect against OS command injection.

How to Validate: Without proper input sanitizing, an attacker could easily modify
the input (as shown below) to manipulate the application into accessing by OS
command and get it in burp.

POC:

[Request]

[Response]
________________

Control Name: Verify that the application does not include and execute
functionality from untrusted sources, such as unverified content distribution
networks, JavaScript libraries, node npm libraries, or server-side DLLs.

How to Validate: Without proper input sanitizing, an attacker could easily modify
the input (as shown below) to manipulate the application into accessing
unauthorized files and directories from the host server using the “../” directive.
This is known as Directory (Path) Traversal. Here I use the website
“http://www.textfiles.com/hacking/”.

POC:
[Request]

[Response]

It executes untrusted sources.

________________

Requirements: File Storage

Control Name: Verify that files obtained from untrusted sources are stored outside
the web root, with limited permissions.

How to Validate: Test the access to the files stored outside of the web root, and
verify that they have limited permissions. This can be done by attempting to access
the files using a web browser or other client, or by attempting to access them
through the file system.

POC:

It accepts all kinds of files and doesn't save them in other locations for safety.
________________

Control Name: Verify that files obtained from untrusted sources are scanned by
antivirus scanners to prevent upload and serving of known malicious content.

How to Validate: Test the access to the files stored outside of the web root, and
verify that they have limited permissions. This can be done by attempting to access
the files using a web browser or other client, or by attempting to access them
through the file system.

POC:

It accepts all kinds of files and doesn't save them in other locations for safety.
________________

Requirements: File Download

Control Name: Verify that the web tier is configured to serve only files with
specific file extensions to prevent unintentional information and source code
leakage. For example, backup files (e.g. .bak), temporary working files
(e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly
used by editors should be blocked unless required.

How to Validate: Check the file system to see if the files obtained from untrusted
sources are stored outside of the web root, with limited permissions. This can be
done using file system utilities, such as 'ls' or 'dir', or by using a file
explorer program.

POC:

It checks the file extension.

________________

Control Name: Verify that direct requests to uploaded files will never be executed
as HTML/JavaScript content.

How to Validate: Check the file system to see if the files obtained from untrusted
sources are stored outside of the web root, with limited permissions. This can be
done using file system utilities, such as 'ls' or 'dir', or by using a file
explorer program.

POC:

It checks the file extension.

________________

Requirements: SSRF Protection

Control Name: Verify that the web or application server is configured with an allow
list of resources or systems to which the server can send requests or load
data/files from.

How to Validate: Test for cross-site scripting (XSS) vulnerabilities by attempting

to inject malicious script into the application. If the allow list is configured
correctly, the script should not be executed. Test for cross-site request forgery
(CSRF) vulnerabilities by attempting to make unauthorized requests from a different
domain. If the allow list is configured correctly, these requests should be
rejected.
POC:

Didn’t accept the unauthorized file access.

________________

Requirements:: Generic Web Service Security

Control Name: Verify that all application components use the same encodings and
parsers to avoid parsing attacks that exploit different URI or file parsing
behavior that could be used in SSRF and RFI attacks.

How to Validate: Test for parser bypasses, such as attempting to inject malicious
data into the application that would be interpreted differently by different
parsers. Ensure that all input is properly validated and sanitized, and that the
application is not vulnerable to attacks that exploit differences in encoding or
parsing behavior. Monitor logs and audit trails for unusual or suspicious activity,
such as repeated attempts to exploit SSRF or RFI vulnerabilities. This can help
detect and prevent parsing attacks.

POC:

Didn’t accept the unauthorized access request.

________________

Control Name: Verify API URLs do not expose sensitive information, such as the API
key, session tokens etc.

How to Validate: Test for parser bypasses, such as attempting to inject malicious
data into the application that would be interpreted differently by different
parsers.

POC:

It didn’t show the cookie in the API request.

________________

Control Name: Verify that requests containing unexpected or missing content types
are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415
Unsupported Media Type)
How to Validate: Test for parser bypasses, such as attempting to inject malicious
data into the application that would be interpreted differently by different
parsers.

POC:

It gives 400 Bad responses.

________________

Requirements: RESTful Web Service

Control Name: Verify that enabled RESTful HTTP methods are a valid choice for the
user or action, such as preventing normal users using DELETE or PUT on protected
API or resources.

How to Validate: Test the usage of HTTP methods, such as DELETE and PUT, to ensure
that they are only available to authorized users and actions. This could include
attempting to use the methods as a normal user or attempting to use the methods on
protected API or resources to verify that proper input validation is in place and
that JSON schema validation is being used to validate inputs before accepting them.
This can help prevent attackers from injecting malicious data into the application.

POC:

It accepts PUT requests without validating that means it is not secured.

________________

Control Name: Verify that JSON schema validation is in place and verified before
accepting input.

How to Validate: Test the usage of HTTP methods, such as DELETE and PUT, to ensure
that they are only available to authorized users and actions. This could include
attempting to use the methods as a normal user or attempting to use the methods on
protected API or resources to verify that proper input validation is in place and
that JSON schema validation is being used to validate inputs before accepting them.
This can help prevent attackers from injecting malicious data into the application.

POC:

It accepts PUT requests without validating json format that means it is not
secured.
________________

Control Name: Verify that RESTful web services that utilize cookies are protected
from Cross-Site Request Forgery via the use of at least one or more of the
following: double submit cookie pattern, CSRF nonces, or Origin request header
checks.

How to Validate: Test the usage of HTTP methods, such as DELETE and PUT, to ensure
that they are only available to authorized users and actions. This could include
attempting to use the methods as a normal user or attempting to use the methods on
protected API or resources to verify that proper input validation is in place and
that JSON schema validation is being used to validate inputs before accepting them.
This can help prevent attackers from injecting malicious data into the application.

POC:

Accept the unauthorized access request.

________________

Requirements:: Build and Deploy

Control Name: Verify that the application build and deployment processes are
performed in a secure and repeatable way, such as CI/CD automation, automated
configuration management, and automated deployment scripts.

How to Validate: Performed penetration testing on the application and the

deployment process. This will help identify any security vulnerabilities and ensure
that the deployment process is secure.

POC:

Here all the procedures are secured.

________________

Control Name: Verify that compiler flags are configured to enable all available
buffer overflow protections and warnings, including stack randomization, data
execution prevention, and to break the build if an unsafe pointer, memory, format
string, integer, or string operations are found.
How to Validate: Performed penetration testing on the application and the
deployment process. This will help identify any security vulnerabilities and ensure
that the deployment process is secure.

POC:

________________

Control Name: Verify that server configuration is hardened as per the

recommendations of the application server and frameworks in use.

How to Validate: Use any deploy site to see the request responses.

POC:

________________

Control Name: Verify that the application, configuration, and all dependencies can
be re-deployed using automated deployment scripts, built from a documented and
tested runbook in a reasonable time, or restored from backups in a timely fashion.

How to Validate: Test the application server to ensure that it only accepts the
HTTP methods in use by the application. This can be done using a tool such as Burp
Suite, OWASP ZAP, or Postman.

POC:

Here request code ‘200 ok’ that means it re-deployed all the dependencies.
________________

Control Name: Verify that authorized administrators can verify the integrity of all
security relevant configurations to detect tampering.

How to Validate: Test the application server to ensure that it only accepts the
HTTP methods in use by the application. This can be done using a tool such as Burp
Suite, OWASP ZAP, or Postman.

POC:
________________

Requirements: Dependency

Control Name: Verify that all components are up to date, preferably using a
dependency checker during build or compile time.

How to Validate: We can check it on the compiler site to see if any kind of error
happened or not.

POC:

No errors happened.
________________

Control Name: Verify that all unneeded features, documentation, sample applications
and configurations are removed.

How to Validate: Check it on the compiler site to see if any kind of error happened
or not.

POC:

No issues happened.
________________

Control Name: Verify that if application assets, such as JavaScript libraries, CSS
or web fonts, are hosted externally on a Content Delivery Network (CDN) or external
provider, Subresource Integrity (SRI) is used to validate the integrity of the
asset.

How to Validate: Send request and see it on Burp.

POC:

________________
Control Name: Verify that third party components come from pre-defined, trusted and
continually maintained repositories.

How to Validate: Send request and see it on Burp.

POC:

________________

Control Name: Verify that a Software Bill of Materials (SBOM) is maintained of all
third party libraries in use.

How to Validate: See on Compiler.

POC:

________________

Control Name: Verify that the attack surface is reduced by sandboxing or

encapsulating third party libraries to expose only the required behavior into the
application.

How to Validate: Inspect the request.

POC:

________________

Requirements: Unintended Security Disclosure

Control Name: Verify that web or application server and application framework debug
modes are disabled in production to eliminate debug features, developer consoles,
and unintended security disclosures.

How to Validate: The configuration of the web or application server and application
framework should be verified to ensure that the debug modes are indeed disabled in
production. This can be done by reviewing the configuration files and making sure
that the appropriate settings are set to disable the debug modes.

POC:

That means Debug mode isn’t false.

________________

Control Name: Verify that the HTTP headers or any part of the HTTP response do not
expose detailed version information of system components.

How to Validate: The configuration of the web or application server and application
framework should be verified to ensure that the debug modes are indeed disabled in
production. This can be done by reviewing the configuration files and making sure
that the appropriate settings are set to disable the debug modes.

POC:

As debug mode isn’t false, it exposes all request methods.

________________

Requirements: HTTP Security Headers

Control Name: Verify that every HTTP response contains a Content-Type header. Also
specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are
text/*, /+xml and application/xml. Content must match with the provided Content-
Type header.

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:

The HttpRequest is false.

________________

Control Name: Verify that all API responses contain a Content-Disposition:

attachment; filename = "api.json" header (or other appropriate filename for the
content type).

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:

It need the json format.

________________

Control Name: Verify that a Content Security Policy (CSP) response header is in
place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and
JavaScript injection vulnerabilities.

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:

As it discloses the URL Requests, it is vulnerable for XSS attacks.

________________

Control Name: Verify that all responses contain a X-Content-Type-Options: nosniff

header.

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:

Set as “nosniff”.
________________
Control Name: Verify that a Strict-Transport-Security header is included on all
responses and for all subdomains, such as Strict- Transport- Security: max-age =
15724800; include Sub-domains.

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:

Max set as 2892000.

________________

Control Name: Verify that a suitable Referrer-Policy header is included to avoid

exposing sensitive information in the URL through the Referer header to untrusted
parties.

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:

As debug is true, it discloses all url requests.

________________

Control Name: Verify that the content of a web application cannot be embedded in a
third-party site by default and that embedding of the exact resources is only
allowed where necessary by using suitable Content-Security-Policy: frame-ancestors
and X-Frame-Options response headers.

How to Validate: By using a tool such as a web proxy, network sniffer, or browser
developer tools to capture the HTTP responses generated by the application. Inspect
the headers of each HTTP response to ensure that they contain a Content-Type
header. If a response does not contain a Content-Type header, it should be flagged
as a potential security vulnerability.

POC:
It is not set as Content-Security-Policy: frame-ancestors and X-Frame-Options
response headers.
________________

Requirements: HTTP Request Header Validation

Control Name: Verify that the application server only accepts the HTTP methods in
use by the application/API, including pre-flight OPTIONS, and logs/alerts on any
requests that are not valid for the application context.

How to Validate: By analyzing the application's code and documentation to determine

which HTTP methods are in use by the application. This includes methods such as
GET, POST, PUT, DELETE, etc. Test the application server to ensure that it only
accepts the HTTP methods in use by the application. This can be done using a tool
such as Burp Suite, OWASP ZAP, or Postman to see if the application generates any
errors.

POC:

HttpOnly is false.
________________

Control Name: Verify that the supplied Origin header is not used for authentication
or access control decisions, as the Origin header can easily be changed by an
attacker.

How to Validate: By analyzing the application's code and documentation to determine

which HTTP methods are in use by the application. This includes methods such as
GET, POST, PUT, DELETE, etc. Test the application server to ensure that it only
accepts the HTTP methods in use by the application. This can be done using a tool
such as Burp Suite, OWASP ZAP, or Postman to see if the application generates any
errors.

POC:

There is no supplied Origin header.

________________

Control Name: Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-
Allow-Origin header uses a strict allow-list of trusted domains and subdomains to
match against and does not support the "null" origin.
How to Validate: By analyzing the application's code and documentation to determine
which HTTP methods are in use by the application. This includes methods such as
GET, POST, PUT, DELETE, etc. Test the application server to ensure that it only
accepts the HTTP methods in use by the application. This can be done using a tool
such as Burp Suite, OWASP ZAP, or Postman to see if the application generates any
errors.

POC:

________________

Control Name: Verify that HTTP headers added by a trusted proxy or SSO devices,
such as a bearer token, are authenticated by the application.

How to Validate: By analyzing the application's code and documentation to determine

which HTTP methods are in use by the application. This includes methods such as
GET, POST, PUT, DELETE, etc. Test the application server to ensure that it only
accepts the HTTP methods in use by the application. This can be done using a tool
such as Burp Suite, OWASP ZAP, or Postman to see if the application generates any
errors.

POC:

A token was generated.