search

blabla1337 / junk

0 stars 1 forks source link

asdasd #8

Open blabla1337 opened 5 years ago

blabla1337 commented 5 years ago

as dad

skf-git-bot[bot] commented 5 years ago

alt text

Security knowledge framework!

Does The application enforce the use of secure passwords

 Description:

Applications should encourage the use of strong passwords and passphrases. Preferably the
password policy should not put limitations or restrictions on the chosen passwords (for example
the length of a password). Whenever the application supports strong passwords and
the use of password managers, the possibility for an attacker performing a succesfull bruteforce 
attack drops significantly.
This also increases the possibility that the application can be used with users' passwords managers.

 Solution:

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent
password managers, long passphrases or highly complex passwords being entered. 
A password ideally should be:
* at least 12 characters in length
* passwords even longer than 64 characters are allowed
* every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)
* No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) 


Does The application enforce the use of secure passwords

 Description:

Applications should encourage the use of strong passwords and passphrases. Preferably the
password policy should not put limitations or restrictions on the chosen passwords (for example
the length of a password). Whenever the application supports strong passwords and
the use of password managers, the possibility for an attacker performing a succesfull bruteforce 
attack drops significantly.
This also increases the possibility that the application can be used with users' passwords managers.

 Solution:

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent
password managers, long passphrases or highly complex passwords being entered. 
A password ideally should be:
* at least 12 characters in length
* passwords even longer than 64 characters are allowed
* every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)
* No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) 


Does The application enforce the use of secure passwords

 Description:

Applications should encourage the use of strong passwords and passphrases. Preferably the
password policy should not put limitations or restrictions on the chosen passwords (for example
the length of a password). Whenever the application supports strong passwords and
the use of password managers, the possibility for an attacker performing a succesfull bruteforce 
attack drops significantly.
This also increases the possibility that the application can be used with users' passwords managers.

 Solution:

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent
password managers, long passphrases or highly complex passwords being entered. 
A password ideally should be:
* at least 12 characters in length
* passwords even longer than 64 characters are allowed
* every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)
* No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) 


Does The application enforce the use of secure passwords

 Description:

Applications should encourage the use of strong passwords and passphrases. Preferably the
password policy should not put limitations or restrictions on the chosen passwords (for example
the length of a password). Whenever the application supports strong passwords and
the use of password managers, the possibility for an attacker performing a succesfull bruteforce 
attack drops significantly.
This also increases the possibility that the application can be used with users' passwords managers.

 Solution:

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent
password managers, long passphrases or highly complex passwords being entered. 
A password ideally should be:
* at least 12 characters in length
* passwords even longer than 64 characters are allowed
* every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)
* No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) 


Permit Password Change

Description:

Users should be able to update their password whenever it is necessary. For example, take in consideration the scenario in which they tend to use the same password for multiple purposes. If this password is leaked, the users have to immediately update their credentials in every application they are registered. Therefore, if the application does not provide an accessible password update functionality to a user, there is the risk that his account may be taken over.

Solution:

Applications should provide to the user a functionality that permits the change of its own password.


Unauthorized credential changes

 Description:

An application which offers user login functionality, usually has an administration page
where userdata can be modified. When the user wants to change this data he should
specify his current password.

 Solution:

When changing user credentials or email address the user must always enter a valid
password in order to implement the changes. This is also called reauthentication or
stepup / adaptive authentication. Whenever a user "reauthenticates" himself the current
session ID value should also be refreshed in order to fend oFf so called "session hijackers"


Verify Breached Passwords

 Description:

Multiple database of leaked credentials have been released during breaches over the years. If users choose passwords already leaked, they are vulnerable to dictionary attacks.

 Solution:

Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords. In case the password chosen has already been breached, the application must require the user to reenter a nonbreached password.


Provide Password Strength Checker

 Description:

Users may tend to choose easy guessable passwords. Therefore, it is suggested to implement a functionality that encourage them to set password of higher complexity.

 Solution:

Applications should provide the users a password security meter in occasion of account registration and password change.


Does The application enforce the use of secure passwords

 Description:

Applications should encourage the use of strong passwords and passphrases. Preferably the
password policy should not put limitations or restrictions on the chosen passwords (for example
the length of a password). Whenever the application supports strong passwords and
the use of password managers, the possibility for an attacker performing a succesfull bruteforce 
attack drops significantly.
This also increases the possibility that the application can be used with users' passwords managers.

 Solution:

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent
password managers, long passphrases or highly complex passwords being entered. 
A password ideally should be:
* at least 12 characters in length
* passwords even longer than 64 characters are allowed
* every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)
* No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) 


no password rotation policy

Description:
Some policies require users to change passwords periodically, often every 90 or 180 days. 
The benefit of password expiration, however, is debatable. Systems that implement such 
policies sometimes prevent users from picking a password too close to a previous selection.

This policy can often backfire. Some users find it hard to devise "good" passwords that are 
also easy to remember, so if people are required to choose many passwords because they have 
to change them often, they end up using much weaker passwords; the policy also encourages 
users to write passwords down. Also, if the policy prevents a user from repeating a recent password, 
this requires that there is a database in existence of everyone's recent passwords (or their hashes) 
instead of having the old ones erased from memory. Finally, users may change their password repeatedly
within a few minutes, and then change back to the one they really want to use, circumventing the 
password change policy altogether.

Solution:
Only force users to update their passwords when the password strength that is enforced by the application
is no longer sufficient to withstand brute force attacks due to increase of computing power.


Does The application enforce the use of secure passwords

 Description:

Applications should encourage the use of strong passwords and passphrases. Preferably the
password policy should not put limitations or restrictions on the chosen passwords (for example
the length of a password). Whenever the application supports strong passwords and
the use of password managers, the possibility for an attacker performing a succesfull bruteforce 
attack drops significantly.
This also increases the possibility that the application can be used with users' passwords managers.

 Solution:

Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent
password managers, long passphrases or highly complex passwords being entered. 
A password ideally should be:
* at least 12 characters in length
* passwords even longer than 64 characters are allowed
* every special characters from Unicode charset should be permitted (including emoki, kanji, multiple whitespaces, ecc.)
* No limit for the number of characters allowed from the same type (lowercase characters, uppercase characters, digits, symbols) 


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


Brute force password guessing

 Description:

Login functions should not be abused in an automated way that an attacker could create a
script that contains a list of usernames and passwords, which he could use against your
login function in order to gain unauthorized access to user accounts.

 Solution:

Implement a method that limits the amount of tries with automated tools.
Some examples are using a CAPTCHA or a TARPIT(ratelimiting) method.

Be aware that a simple limitation on number of tries may be used as a method to perform denialofservice attack and hence to block certain users like system administrator from logging in. A mechanism combines tries limit with challengeresponse test can be used to prevent this risk while providing convenience for actual user login. For example, start to ask user to complete a CAPTCHA or a TARPIT question during login after a certain number of tries is reached.


Forget password functions

 Description:

Whenever the application provides a password forget functionality or another 
type of recovery methods there are several implementations of hardened proven ways to make
the user recover his password.

 Solution:

The recommended solutions are to use TOTP (Timebased OneTime Password algorithm). This 
method is an example of a hashbased message authentication code (HMAC). It combines a 
secret key with the current timestamp using a cryptographic hash function to generate 
a onetime password. Because network latency and outofsync clocks can result in the password 
recipient having to try a range of possible times to authenticate against, the timestamp typically 
increases in 30second intervals, which thus cuts the potential search space.

Or the other option is to use a Mathematicalalgorithmbased onetime password method. This other 
type of onetime password uses a complex mathematical algorithm, such as a hash chain, to generate 
a series of onetime passwords from a secret shared key. Each password cannot be guessed even when 
previous passwords are known. The open source OAuth algorithm is standardized; other algorithms are 
covered by U.S. patents. Each password is observably unpredictable and independent on previous ones. 
Therefore, an adversary would be unable to guess what the next password may be, even with the 
knowledge of all previous passwords.

Example of a hard token mathimatical algorithm would be a yubikey
Example of a soft token TOTP would be google authenticator

The last resort would be to send a new password by email. This mail should contain a reset link with 
a token which is valid for a limited amount of time. Additional authentication based on softtokens 
(e.g. SMS token, native mobile applications, etc.) can be required as well before the link is 
sent over. Also, make sure whenever such a recovery cycle is started, the application does not 
reveal the user’s current password in any way.


user notification on critical state changing operations

Description:
When a user is informed of critical operations than the user can determine
if the notification is send by his own actions, or that the notifucation indicates 
potential compromitation of his user account.

Solution:

Verify that secure notifications are sent to users after updates
to authentication details, such as credential resets, email or address changes,
logging in from unknown or risky locations. Users must also be notified when
password policies change or any other important updates that require action from the
user to increase the security of his account.

The use of push notifications  rather than SMS or email  is preferred, but in the 
absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed 
in the notification.


Secrets should be secure random generated

 Description:

Secret keys, API tokens, or passwords must be dynamically generated. Whenever these tokens
are not dynamically generated they can become predicable and used by attackers to compromise
user accounts. 

 Solution:

When it comes to API tokens and secret keys these values have to be dynamically generated and valid only once.
The secret token should be cryptographically 'random secure', with at least 120 bit of effective entropy, salted with a unique and random 32bit value and hashed with an approved hashing (oneway) function.

Passwords on the other hand should be created by the user himself, rather than assigning
a user a dynamically generated password. The user should be presented a onetime link with a 
cryptographically random token by means of an email or SMS which is used to activate his 
account and provide a password of his own.


Password leakage

 Description:

After completing a password recovery functionality, the user should not be sent a plaintext
password to his email adress. The application should also under no circumstances disclose the old or current password
to the users.

 Solution:

The application should under no circumstances disclose the users current, old and new password plain text.
This behavior makes the application susceptible to side channel attacks and make the passwords
lose their integrity since they could be compromised by someone looking over another users shoulder to
see the password. 


No shared knowledge for secret questions

 Description:

Whenever an application ask an user a secret question i.e a password forgot
functionality, these questions should not be shared knowledge an attacker could get from
the web to prevent him compromising the account by this function.

 Solution:

Secret questions should never include shared knowledge, predictable or easy
guessable values.

Otherwise the answers for these secret questions can be easilly looked up on the internet by means 
of social media accounts and the like.


Password leakage

 Description:

After completing a password recovery functionality, the user should not be sent a plaintext
password to his email adress. The application should also under no circumstances disclose the old or current password
to the users.

 Solution:

The application should under no circumstances disclose the users current, old and new password plain text.
This behavior makes the application susceptible to side channel attacks and make the passwords
lose their integrity since they could be compromised by someone looking over another users shoulder to
see the password. 


Avoid the use of default and predictable acounts.

 Description:

Whenever default or predictable accounts are available on an application/server this could
lead to an attacker compromising these services. Make sure all default and predictable
accounts are disabled or deleted from the services.

 Solution:

Verify that all keys and passwords are replaceable, and are generated or
replaced after installation time.


user notification on critical state changing operations

Description:
When a user is informed of critical operations than the user can determine
if the notification is send by his own actions, or that the notifucation indicates 
potential compromitation of his user account.

Solution:

Verify that secure notifications are sent to users after updates
to authentication details, such as credential resets, email or address changes,
logging in from unknown or risky locations. Users must also be notified when
password policies change or any other important updates that require action from the
user to increase the security of his account.

The use of push notifications  rather than SMS or email  is preferred, but in the 
absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed 
in the notification.


Forget password functions

 Description:

Whenever the application provides a password forget functionality or another 
type of recovery methods there are several implementations of hardened proven ways to make
the user recover his password.

 Solution:

The recommended solutions are to use TOTP (Timebased OneTime Password algorithm). This 
method is an example of a hashbased message authentication code (HMAC). It combines a 
secret key with the current timestamp using a cryptographic hash function to generate 
a onetime password. Because network latency and outofsync clocks can result in the password 
recipient having to try a range of possible times to authenticate against, the timestamp typically 
increases in 30second intervals, which thus cuts the potential search space.

Or the other option is to use a Mathematicalalgorithmbased onetime password method. This other 
type of onetime password uses a complex mathematical algorithm, such as a hash chain, to generate 
a series of onetime passwords from a secret shared key. Each password cannot be guessed even when 
previous passwords are known. The open source OAuth algorithm is standardized; other algorithms are 
covered by U.S. patents. Each password is observably unpredictable and independent on previous ones. 
Therefore, an adversary would be unable to guess what the next password may be, even with the 
knowledge of all previous passwords.

Example of a hard token mathimatical algorithm would be a yubikey
Example of a soft token TOTP would be google authenticator

The last resort would be to send a new password by email. This mail should contain a reset link with 
a token which is valid for a limited amount of time. Additional authentication based on softtokens 
(e.g. SMS token, native mobile applications, etc.) can be required as well before the link is 
sent over. Also, make sure whenever such a recovery cycle is started, the application does not 
reveal the user’s current password in any way.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


Verify that the sensitive information is never disclosed

 Description:

Information exposure through query strings in URL is when sensitive data is passed to parameters in the URL. This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data. Simply using HTTPS does not resolve this vulnerability.

Regardless of using encryption, the following URL will expose information in the locations detailed below: https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations 
when using HTTP or HTTPS:

 Referer Header
 Web Logs
 Shared Systems
 Browser History
 Browser Cache
 Shoulder Surfing

When not using an encrypted channel, all of the above and the following:
 ManintheMiddle

 Solution:

Sensitive informtion should never be included in the URL.


The login functionality should always generate a new session id

 Description:

Whenever an user is successfully authenticated the application should generate a
new session cookie.

 Solution:

The login functionality should always generate (and use) a new session ID after a
successful login. This is done to prevent an attacker doing a session fixation attack
on your users.

Some frameworks do not provide the possibility to change the session ID on login such as
.net applications. Whenever this problem occurs you could set an extra random cookie on
login  with a strong token and store this value in a session variable.

Now you can compare the cookie value with the session variable in order to prevent
session fixation since the authentication does not solely rely on the session ID since
the random cookie can not be predicted or fixated by the attacker.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


The logout functionality should revoke the complete session

 Description:

When the logout functionality does not revoke the complete session, an attacker could still
impersonate a user when he has access to the session cookie even after the user is logged off the application.

 Solution:

The logout functionality should revoke the complete session whenever a user
wants to terminate his session.

Each different framework has its own guide to achieve this revocation.
It is also recommended for you to make test cases which you follow to ensure
session revocation in your application.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


Password change leads to destroying concurrent sessions

 Description:

Whenever a user changes his password, the user should be granted the option
to kill all other concurrent sessions. This countermessure helps to exclude
potential attackers living on a hijacked session.

Note: Whenever users are granted the possibility to change their passwords,
      do not forget to make them reauthenticate or to use a form of step up
      or adaptive authentication mechanism.

 Solution:

Verify the user is prompted with the option to terminate all other active sessions 
after a successful change password process.


concurrent session handling

 Description:

You should keep track of all the different active concurrent sessions.
Whenever the application discovers concurrent sessions it should always notify the user
about this and should give him the opportunity to end the other sessions.

With this defense in place it becomes harder for attackers to hijack a users session since
they will be notified about concurrent sessions.

 Solution:

The application should keep track and limit all the granted sessions.
It should store your users IP address, session id and user id. After storing these credentials
it should do regular checks to see if there are:

1. Multiple active sessions linked to same user id
2. Multiple active sessions from different locations
3. Multiple active sessions from different devices
4. Limit and destroy sessions when they exceed an accepted threshold.

The more critical the application becomes, the lower the accepted threshold for
concurrent sessions should be.


Session cookies without the Secure attribute

 Description:

The secure flag is an option that can be set when creating a cookie.
This flag ensures that the cookie will not be sent over an unencrypted
connection by the browser,which ensures that the session cookie can not be sent over a nonencrypted link.

 Solution:

When creating a session cookie which is sent over an encrypted connection
you should set the secure flag. The Secure flag should be set during every setcookie.
This will instruct the browser to never send the cookie over HTTP.
The purpose of this flag is to prevent the accidental exposure of a cookie value if a user
follows an HTTP link.


Session cookies without the HttpOnly attribute

 Description:

An HttpOnly flag is an option that can be set when creating a cookie. This v ensures that the cookie cannot be read or edited by JavaScript. This ensures an attacker cannot steal this cookie as a crosssite scripting vulnerability is present in the application.

 Solution:

The HttpOnly flag should be set to disable malicious script access to the cookie values such as the session ID value. Also, disable unnecessary HTTP request methods such as the TRACE option. Misconfiguration of the HTTP request headers can lead to stealing the session cookie even though HttpOnly protection is in place.


same site attribute

Description:
SameSite prevents the browser from sending this cookie along with crosssite requests. 
The main goal is mitigate the risk of crossorigin information leakage. It also provides some 
protection against crosssite request forgery attacks.

Solution:
The strict value will prevent the cookie from being sent by the browser to the target site in all 
crosssite browsing context, even when following a regular link. For example, for a GitHublike website this 
would mean that if a loggedin user follows a link to a private GitHub project posted on a corporate discussion 
forum or email, GitHub will not receive the session cookie and the user will not be able to access the project.

A bank website however most likely doesn't want to allow any transactional pages to be linked from external 
sites so the strict flag would be most appropriate here.

The default lax value provides a reasonable balance between security and usability for websites that want
to maintain user's loggedin session after the user arrives from an external link. In the above GitHub scenario, 
the session cookie would be allowed when following a regular link from an external website while blocking it in 
CSRFprone request methods (e.g. POST).

As of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera. 
Since version 12.1 Safari also supports this. Windows 7 with IE 11 lacks support as of December 2018, 
see caniuse.com below.


host prefix

Description:

the '__Host" prefix signals to the browser that both the Path=/ and Secure attributes are required, 
and at the same time, that the Domain attribute may not be present.


Cross subdomain cookie attack

 Description:

A quick overview of how it works:

1. A website www.example.com hands out subdomains to untrusted third parties
2. One such party, Mallory, who now controls evil.example.com, lures Alice to her site
3. A visit to evil.example.com sets a session cookie with the domain .example.com on Alice's browser
4. When Alice visits www.example.com, this cookie will be sent with the request, as the specs for cookies states, and Alice will have the session specified by Mallory's cookie.
5. Mallory can now use Alice her account.

 Solution:

In this scenario changing the sessionID on login does not make any difference since
Alice is already logged in when she visits Mallory's evil web page.

It is good practice to use a completely different domain for all trusted activity.

For example Google uses google.com for trusted activities and *.googleusercontent.com
for untrusted sites.

Also when setting your cookies to specify which domains they are allowed to
be send to. Especially on your trusted domain you do not want to leak cookies to unintended
subdomains. highly recommended is to not use wildcards when setting this option.


High value transactions

 Description:

Whenever there are high value transactions a normal username/password static authentication method does
not suffice to ensure a high level of security. Whenever the application digests high level of transactions ensure that
risk based reauthentication, two factor or transaction signing is in place.

 Solution:

1 risk based authentication:
In Authentication, riskbased authentication is a nonstatic authentication 
system which takes into account the profile of the agent requesting access to 
the system to determine the risk profile associated with that transaction. 

The risk profile is then used to determine the complexity of the challenge.
Higher risk profiles leads to stronger challenges, whereas a static username/password may suffice for 
lowerrisk profiles. Riskbased implementation allows the application to challenge the user for additional 
credentials only when the risk level is appropriate.

2 two factor authentication:
Multifactor authentication (MFA) is a method of computer access control in which a user is 
granted access only after successfully presenting several separate pieces of evidence to an 
authentication mechanism – typically at least two of the following categories: knowledge (something they know), 
possession (something they have), and inherence (something they are)

3 Transaction signing:
Transaction signing (or digital transaction signing) is the process of calculating a keyed hash function 
to generate a unique string which can be used to verify both the authenticity and integrity of an online transaction.

A keyed hash is a function of the user's private or secret key and the transaction details, 
such as the transfer to the account number and the transfer amount.

To provide a high level of assurance of the authenticity and integrity of 
the hash it is essential to calculate the hash on a trusted device, such as a separate smart card reader.
Calculating a hash on an Internetconnected PC or mobile device such as a mobile telephone/PDA would be
counterproductive as malware and attackers can attack these platforms and potentially subvert the signing process itself.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


not available item

 Description:

This item is currently not available.

 Solution:

This item is currently not available.


All authentication controls must fail securely

 Description:

Handling errors securely is a key aspect of secure coding.
There are two types of errors that deserve special attention. The first is exceptions
that occur in the processing of a security control itself. It's important that these
exceptions do not enable behavior that the countermeasure would normally not allow.
As a developer, you should consider that there are generally three possible outcomes
from a security mechanism:

1. Allow the operation
2. Disallow the operation
3. Exception

In general, you should design your security mechanism so that a failure will follow the same execution path
as disabling the operation

 Solution:

Make sure all the access control systems are thoroughly tested for failing securely before
using it in your application. It is common that complete unittest are created especially
for this purpose.


Insecure direct object references

 Description:

Applications frequently use the actual name or key of an object when generating web pages. 
Applications don’t always verify the user is authorized for the target object. 
This results in an insecure direct object reference flaw. Testers can easily manipulate parameter 
values to detect such flaws and code analysis quickly shows whether authorization is properly verified.

The most classic example:
The application uses unverified data in a SQL call that is accessing account information:

String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , ... );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();

The attacker simply modifies the ‘acct’ parameter in their browser to send whatever 
account number they want. If not verified, the attacker can access any user’s account, instead of 
only the intended customer’s account.

http://example.com/app/accountInfo?acct=notmyacct

 Solution:

Preventing insecure direct object references requires selecting an approach 
for protecting each user accessible object (e.g., object number, filename):

Use per user or session indirect object references. This prevents attackers from directly 
targeting unauthorized resources. For example, instead of using the resource’s database key, 
a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to 
indicate which value the user selected. The application has to map the peruser indirect reference 
back to the actual database key on the server.

Check access. Each use of a direct object reference from an untrusted source must include an access control 
check to ensure the user is authorized for the requested object.


Cross site request forgery

 Description:

CrossSite Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site,
email, blog, instant message, or program causes a users Web browser to perform an unwanted
action on a trusted site for which the user is currently authenticated.

The impact of a successful crosssite request forgery attack is limited to the
capabilities exposed by the vulnerable application. For example, this attack could result
in a transfer of funds, changing a password, or purchasing an item in the users context.
In effect, CSRF attacks are used by an attacker to make a target system perform a
function (funds Transfer, form submission etc.) via the targets browser without
knowledge of the target user at least until the unauthorised function has been committed.

 Solution:

To arm an application against automated attacks and tooling you need to use unique tokens
which are included into the forms of an application, API calls or AJAX requests.  
Any state changing operation requires a secure random token (e.g CSRF token) to prevent
against CSRF attacks. Characteristics of a CSRF Token are a unique, large random
value generated by a cryptographically secure random number generator.

The CSRF token is then added as a hidden field for forms and validated on the sever side whenever
a user is sending a request to the server.

Note :
Whenever the application is an REST service and is using tokens such as JWT tokens, whenever these tokens are being sent
in the application headers rather than stored in cookies the application should not be suspectible to CSRF attacks for a succesfull CSRF attacke depends on the browsers cookie jar.


Two factor authentication

 Description:

Two factor authenitcation must be implemented to protect your applications users against unauthorized use of the application.

Whenever the users username and password are leaked or disclosed by an application on what ever fashion possible, the 
users account should still be proteced by two factor authentication mechanisms to prevent attackers
from logging in with the credentials.

 Solution:

Multifactor authentication (MFA) is a method of computer access control in which a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism – typically at least two of the following categories: knowledge (something they know), possession (something they have), and inherence (something they are)

Examples of two/multi factor authentication can be 

1. Google authenticator
   Google Authenticator is an application that implements twostep verification services using the Timebased 
   Onetime Password Algorithm (TOTP) and HMACbased Onetime Password Algorithm 

2. Yubikey

  The YubiKey is a hardware authentication device manufactured by Yubico that supports onetime passwords, public key   
  encryption and authentication, and the Universal 2nd Factor (U2F) protocol[1] developed by the FIDO Alliance (FIDO U2F).
  It allows users to securely log into their accounts by emitting onetime passwords or using a FIDObased public/private
  key pair generated by the device


Directory listing

 Description:

Whenever directory listing is enabled, an attacker could gain sensitive information about
the systems hierarchical structure and gain knowledge about directories or files which should
possibly not be publicly accessible. An attacker could use this information to
increase his attack vector. In some cases this could even lead to an attacker gaining knowledge about
credentials or old vulnerable system demo functions which might lead to remote code execution.

 Solution:

Different types of servers require a different type of approach in order to disable
directory listing. For instance: Apache uses a .htacces in order to disable directory listing.
As for iis7, directory listing is disabled by default.


Step up or adaptive authentication

 Description:

Whenever a user browses a section of a webbased application that contains sensitive information the user should be challenged authenticate again using a higher assurance credential to be granted access to this information.
This is to prevent attackers from reading sensitive information after they successfully hijacked a user account.

 Solution:

Verify the application has additional authorization (such as step up or adaptive authentication) so the user is challenged before being granted access to sensitive information. This rule also applies for making critical changes to an account or action.
Segregation of duties should be applied for highvalue applications to enforce antifraud controls as per the risk of application and past fraud.


HTTP header injection

 Description:

HTTP header injection is a general class of web application security vulnerability which
occurs when Hypertext Transfer Protocol (HTTP) headers are
dynamically generated based on user input. Header injection in HTTP responses can allow
for HTTP response splitting (also known as CRLF, Carriage Return Line Feed),
Session fixation via the SetCookie header, crosssite scripting (XSS),
and malicious redirect attacks via the location header. HTTP header injection is a
relatively new area for webbased attacks, and has primarily been pioneered
by Amit Klein in his work on request/response smuggling/splitting.
Vulnerabilities due to HTTP header injections such as CRLF are no longer
feasible due to the fact that multiple header requests are not possible.

 Solution:

When userinput will be used in HTTP headers then the newlines should be escaped in a
correct manner. Recommended would be a whitelist of expected input or use a validation method
which for example only accepts alphanumeric values. Every detection of input which is out of
the intended operation should be rejected.


Automatic parameter binding

 Description:

If the application framework allows automatic mass parameter assignment
(also called automatic variable binding) from the inbound request to a model,
verify that security sensitive fields such as 'accountBalance', 'role' or 'password'
are protected from malicious automatic binding. Whenever your application takes parameters
in HTTPs GET statement and passes them as variables to code within the application this
could become a safety hazard since the application processes these variables
in his operations.

 Solution:

When working with automatic variable binding you should create whitelists of what
parameters are expected and allow only these parameters to be passed into your
application operation.


Positive validation model

 Description:

There are two popular methods for handling input validation. The first is blacklisting and the second one is the whitelisting method, also known as a positive validation model.
The big disadvantage of the blacklisting model would be that an attacker has a great diversity into forging his attack strings and payloads which can make it hard for your application to detect all of them. It would be very time consuming importing them all into your system.
Whenever you are using a positive validation model you are simply checking for the input you were expecting as defined in your application’s operation, for example:

Let's say you have a form and were expecting it to return the value of a checkbox. This would be a fixed value, yes or no? Whenever the value diverges from the expected input in the applications operation you can assume there was an intercepting proxy tampering these values and act accordingly to it. 
Same goes for whenever you were expecting just a string, integer, alphanumeric character or even special strings such as names as O’Reily.
This method also makes your code clear, transparent and highly maintainable.

 Solution:

First there must be a client side input validation method as you would apply to the server
side. This means you should also apply input rejection as well as typecasting and such.
This is to prevent users from being attacked by XSS attacks which are undetectable by
the server.


Verify that structured data is strongly typed and validated

 Description:

Whenever structured data is strongly typed and validated against a defined schema the application
can be developed as a defensible proactive application. The application can now measure everything
that is outside of its intending operation by means of the defined schema's and should be used to
reject the input if the schema checks return false.

 Solution:

Verify that structured data is strongly typed and validated against a defined schema
including allowed characters, length and pattern (e.g. credit card numbers or telephone, 
or validating that two related fields are reasonable, such as validating suburbs and zip or 
post codes match


Open forward and Open redirects

 Description:

Unvalidated redirects and forwards are possible when a web application accepts untrusted
input that could cause the web application to redirect the request to a URL contained
within the untrusted input. By modifying untrusted URL input to a malicious site, an attacker
may successfully launch a phishing scam and steal user credentials. Because the server
name in the modified link is identical to the original site, phishing attempts may have
a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used
to maliciously craft a URL that would pass the application's access control check and
then forward the attacker to privileged functions that they would normally not be able
to access.

 Solution:

Use a whitelisting method for determining where the user should be redirected towards.
You could also show a warning when redirecting to potentially untrusted content.

If not deemed necessary user supplied input should not be used in redirects and forwards anyways.


WYSIWYG editors

 Description:

WYSIWYG editors can be a great risk to your web application since it allows direct
HTML as input to make the user perform styling on their submissions. This is why the
editor should be put under a strict sanitation protocol to prevent injections.

The first thing to take into consideration whenever you want to use WYSIWYG editors on
your web application is to use as limited options as possible. Only the options which
are necessary for your applications intended operation should be applied. This decreases
the attackers attack vector drastically and leaves less room for error in your WYSIWYG
editor in terms of your HTML sanitation.

When providing your web application with an WYSIWYG editor you should also take note that
most people just want to use bullets, make text bold or underline some text. They mostly
do not understand half the functionalities the editors are providing.

 Solution:

Download a HTML sanitizer and configure it to your specific needs. When configuring the sanitizer make sure
you disable all unused components. The less options an attacker has to insert into your application the less
his attack surface becomes. Also before implementing this HTML sanitizer on a production environment have
it first thoroughly examined by security testers since it is a very delicate function.


type checking and length checking

 Description

Type checking, length checking and whitelisting is an essential in defense in depth strategie to make
your application more resiliant against input injection attacks.

Example:
SELECT * FROM pages WHERE id=mysql_real_escape_string($_GET['id'])
```

This PHP example did effectively not mitigate the SQL injection. This was due to the fact that it only escaped string based SQL injection.

Now, if this application also had additional checks to validate if the value of the $_GET['id'] parameter was indeed as expected an integer and rejected if this condition was false, the attack would effectively been mitigated.

Solution

All the user supplied input that works outside of the intended opteration of the application should be rejected by the application.

Syntax and Semantic Validity An application should check that data is both syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user).

Syntax validity, means that the data is in the form that is expected. For example, an application may allow a user to select a fourdigit “account ID” to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization).

Semantic validity, includes only accepting input that is within an acceptable range for the given application functionality and context. For example, a start date must be before an end date when choosing date ranges.

</details>

___

- [ ] 5.2.3 Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
<details><summary>More information</summary>

SMTP IMAP injection

Description:

This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not being properly sanitized.

The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing.

An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the frontend web servers. Therefore, mail server results may be more vulnerable to attacks by end users

</details>

___

- [ ] 5.2.4 Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.
<details><summary>More information</summary>

Command injection

Description:

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attackersupplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation. This attack differs from Code Injection, in that code injection allows the attacker to adds his own code that is then executed by the application. In Code Injection, the attacker extends the default functionality of the application without the necessity of executing system commands.

Solution:

Userinput that is used in a shell command should not contain dangerous characters. A blacklist of characters is not a good option because it may be difficult to think of all of the characters to validate against. A white list containing only allowable characters should be created to validate the userinput.

</details>

___

- [ ] 5.2.5 Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.
<details><summary>More information</summary>

server side template injection

Description

Whenever user supplied input is embeded directly into a template when the application makes use of a templeating engine (jinja2, twig, Freemarker), a malicious attacker can inject and execute template expressions. More often the injection of template expressions will ultimately lead to RCE vulnerabilities.

This type of vulnerability is also seen a lot through applications that let the user intentionally modify the template to provide users a more flexible way to style the applications pages like a wiki page or CMS system.

Solution

User supplied input should never be used directly into a template that uses a templating engine. The following example is a small python flask function that renders user supplied input as part of the template. This allows a malicious attacker to even execute arbitrary commands when.

  @app.errorhandler(404)
  def page_not_found(e):
      template = """
  <html>
  <p>{0}</p>
  </html>

  """.format(request.url)
      return render_template_string(template), 404

The prefered way to add the user supplied input to this template would be:

  @app.errorhandler(404)
  def page_not_found(e):
    input = request.url
    return render_template("errorpage.html", input = input), 404

Wheras the content of the errorpage.html would look like

  <html>
      <p>{{input}}</p>
  </html>
</details>

___

- [ ] 5.2.6 Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, use whitelisting of protocols, domains, paths and ports.
<details><summary>More information</summary>

Server side request forgery

Description:

Server Side Request Forgery (SSRF) attack, where an attacker abuse the functionality of a vulnerable web application to send crafter request which which read or update internal resources. Attacker can attack an internal network or application behind the firewall with this attack which is normally not accessible through external network and even attack the internal network web applications.

SSRF attack can be used to make requests to other internal resources for accessing the metadata and to run a port can on the internal network. URL schema such as file:// can be used to read the file from the server. Attackers can use legacy URL schemas such as dict, gopher, expect etc which can even cause remote code execution.

Solution:

Disable unused URL schemas which are dangerous like expect://, file:///, ftp://, gopher://. Proper whitelisting of domain or IP address which you need to access to. Response received from the internal server should not be shown to the attacker. Some services like Memcached, Redis, Elasticsearch and MongoDB do not require authentication by default, so we need to enable authentication for these services.

</details>

___

- [ ] 5.2.7 Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 5.2.8 Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.
<details><summary>More information</summary>

user supplied scriptable or expression template language content

Description:

usersupplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar are designed to give users the option to add a lot of rich styling to the application. However whenever these templates do not filter for harmfull attacks, these templates can be used to leverage XSS attacks.

Solution:

Verify that the application sanitizes, disables, or sandboxes usersupplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.

How this is most effectively done depends on the framework and library you are choosing to incorperate. It is advised to investigate how to put up constraints for translating these template syntaxes to HTML tags and what their security implications are. 

</details>

___

- [ ] 5.3.1 Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara).
<details><summary>More information</summary>

type checking and length checking

Description

Type checking, length checking and whitelisting is an essential in defense in depth strategie to make your application more resiliant against input injection attacks.

Example:

    SELECT * FROM pages WHERE id=mysql_real_escape_string($_GET['id'])

This PHP example did effectively not mitigate the SQL injection. This was due to the fact that it only escaped string based SQL injection.

Now, if this application also had additional checks to validate if the value of the $_GET['id'] parameter was indeed as expected an integer and rejected if this condition was false, the attack would effectively been mitigated.

Solution

All the user supplied input that works outside of the intended opteration of the application should be rejected by the application.

Syntax and Semantic Validity An application should check that data is both syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user).

Syntax validity, means that the data is in the form that is expected. For example, an application may allow a user to select a fourdigit “account ID” to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization).

Semantic validity, includes only accepting input that is within an acceptable range for the given application functionality and context. For example, a start date must be before an end date when choosing date ranges.

</details>

___

- [ ] 5.3.2 Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 5.3.3 Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
<details><summary>More information</summary>

XSS injection

Description:

Every time the application gets userinput, whether this showing it on screen or processing this data in the application background, these parameters should be escaped for malicious code in order to prevent crosssite scripting injections. When an attacker gains the possibility to perform an XSS injection, he is given the opportunity to inject HTML and JavaScript code directly into the application. This could lead to accounts being compromised by stealing session cookies or directly affect the operation of the target application.

Altough templating engines(razor, twig, jinja, etc) and contextaware applications(Angular, React, etc) do a lot of auto escaping for you. These frameworks should always be validated for effectiveness.

Solution:

In order to prevent XSS injections, all userinput should be escaped or encoded. You could start by sanitizing userinput as soon as it is inserted into the application, by preference using a so called whitelisting method. This means you should not check for malicious content like the tags or anything, but only allow the expected input. Every input which is outside of the intended operation of the application should immediately be detected and login rejected. Do not try to help use the input in any way because that could introduce a new type of attack by converting characters.

The second step would be encoding all the parameters or userinput before putting this in your html with encoding libraries specially designed for this purpose.

You should take into consideration that there are several contexts for encoding userinput for escaping XSS injections. These contexts are amongst others:

JavaScript encoding should be used whenever parameters are rendered via JavaScript; your application will detect normal injections in the first instant. But your application still remains vulnerable to JavaScript encoding which will not be detected by the normal encoding/escaping methods.

</details>

___

- [ ] 5.3.4 Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

Prepared statements and query parameterization

Description:

All SQL queries, HQL, OSQL, NOSQL and stored procedures, related to stored procedures should be protected by the use of query parameterization. If an attacker can inject malicious code into these queries and gain the ability to manipulate them and can withdraw, update and delete data which is stored on the target database.

Solution:

The use of prepared statements and parameterized queries is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.

</details>

___

- [ ] 5.3.5 Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection.
<details><summary>More information</summary>

type checking and length checking

Description

Type checking, length checking and whitelisting is an essential in defense in depth strategie to make your application more resiliant against input injection attacks.

Example:

    SELECT * FROM pages WHERE id=mysql_real_escape_string($_GET['id'])

This PHP example did effectively not mitigate the SQL injection. This was due to the fact that it only escaped string based SQL injection.

Now, if this application also had additional checks to validate if the value of the $_GET['id'] parameter was indeed as expected an integer and rejected if this condition was false, the attack would effectively been mitigated.

Solution

All the user supplied input that works outside of the intended opteration of the application should be rejected by the application.

Syntax and Semantic Validity An application should check that data is both syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user).

Syntax validity, means that the data is in the form that is expected. For example, an application may allow a user to select a fourdigit “account ID” to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization).

Semantic validity, includes only accepting input that is within an acceptable range for the given application functionality and context. For example, a start date must be before an end date when choosing date ranges.

</details>

___

- [ ] 5.3.6 Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation.
<details><summary>More information</summary>

Parsing JSON with Javascript

Description:

The eval() function evaluates or executes an argument.

If the argument is an expression, eval() evaluates the expression. If the argument is one or more JavaScript statements, eval() executes the statements.

This is exactly the reason why eval() should NEVER be used to parse JSON or other formats of data which could possible contain malicious code.

Solution:

For the purpose of parsing JSON we would recommend the use of the json.parse functionality. Even though this function is more trusted you should always build your own security checks and encoding routines around the json.parse before mutating the data or passing it on to a view to be displayed in your HTML.

</details>

___

- [ ] 5.3.7 Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

LDAP injection

Description:

LDAP (Lightweight Directory Access Protocol) Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it is possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

Solution:

The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries does not contain any attacks. However, in some cases, it is necessary to include special characters in the input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually part of the LDAP query.

</details>

___

- [ ] 5.3.8 Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

Command injection

Description:

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attackersupplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation. This attack differs from Code Injection, in that code injection allows the attacker to adds his own code that is then executed by the application. In Code Injection, the attacker extends the default functionality of the application without the necessity of executing system commands.

Solution:

Userinput that is used in a shell command should not contain dangerous characters. A blacklist of characters is not a good option because it may be difficult to think of all of the characters to validate against. A white list containing only allowable characters should be created to validate the userinput.

</details>

___

- [ ] 5.3.9 Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
<details><summary>More information</summary>

Filename injection Path traversal

Description:

A Path Traversal attack aims to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with dotdotslash (../); sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and critical system files, limited by system operational access control. The attacker uses ../../ sequences to move up to root directory, thus permitting navigation through the file system. This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack.

Solution:

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing usersubmitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included on the page, and then use an identifier (for example the index number) to access the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

</details>

___

- [ ] 5.3.10 Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

XML attacks

Description:

Whenever you are using XML in your application there are a few possibilities for injections depending on how you are applying XML in your system.

Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format which is both humanreadable and machinereadable. It is defined by the W3C's XML 1.0 Specification and by several other related specifications, all of which are free open standards.

Solution:

Items listed below are recommended to read whenever you are planning to use XML in your application.

Recommended knowledge base items:

XML injection External DTD parsing XSLT injections XPath injections XXE injections

</details>

___

- [ ] 5.5.1 Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.
<details><summary>More information</summary>

Insecure object deserialization

Description:

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications.

Deserialization is the reverse of that process, taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process.

Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denialofservice, access control, and remote code execution (RCE) attacks.

Solution:

Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.

A great reduction of risk is achieved by avoiding native (de)serialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a datatransfer object pattern that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

</details>

___

- [ ] 5.5.2 Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XXE.
<details><summary>More information</summary>

XXE injections

Description:

Processing of an Xml eXternal Entity containing tainted data may lead to the disclosure of confidential information and other system impacts. The XML 1.0 standard defines the structure of an XML document. The standard defines a concept called an entity, which is a storage unit of some type.

There exists a specific type of entity, an external general parsed entity often shortened to an external entity, that can access local or remote content via a declared system identifier and the XML processor may disclose confidential information normally not accessible by the application. Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data.

Solution:

Disable the possibility to fetch resources from an external source. This is normally done in the configuration of the used XML parser.

</details>

___

- [ ] 5.5.3 Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).
<details><summary>More information</summary>

Insecure object deserialization

Description:

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications.

Deserialization is the reverse of that process, taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process.

Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denialofservice, access control, and remote code execution (RCE) attacks.

Solution:

Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.

A great reduction of risk is achieved by avoiding native (de)serialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a datatransfer object pattern that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

</details>

___

- [ ] 5.5.4 Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.
<details><summary>More information</summary>

Parsing JSON with Javascript

Description:

The eval() function evaluates or executes an argument.

If the argument is an expression, eval() evaluates the expression. If the argument is one or more JavaScript statements, eval() executes the statements.

This is exactly the reason why eval() should NEVER be used to parse JSON or other formats of data which could possible contain malicious code.

Solution:

For the purpose of parsing JSON we would recommend the use of the json.parse functionality. Even though this function is more trusted you should always build your own security checks and encoding routines around the json.parse before mutating the data or passing it on to a view to be displayed in your HTML.

</details>

___

- [ ] 6.0 Stored Cryptography Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 6.2.1 Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
<details><summary>More information</summary>

Cryptographic modules must fail securely

Description:

Whenever a cryptographic module does not fail securely this the device needs to be put in error state so it's not useable anymore.

Solution:

We recommend using the National Institute of Standards and Technology (NIST) standard on testing the cryptographic module making it perform the selftests to see if it fails securely.

</details>

___

- [ ] 7.0 Error Handling and Logging Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 7.1.1 Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

User credentials in audit logs

Description:

Whenever there are user credentials supplied in an audit log, this could become a risk whenever an attacker could gain access to one of these log files.

Solution:

Instead of storing user credentials, you may want to use user ID's in order to identify the user in the log files.

</details>

___

- [ ] 7.1.2 Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

User credentials in audit logs

Description:

Whenever there are user credentials supplied in an audit log, this could become a risk whenever an attacker could gain access to one of these log files.

Solution:

Instead of storing user credentials, you may want to use user ID's in order to identify the user in the log files.

</details>

___

- [ ] 7.4.1 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.  ([C10](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

Verbose error messaging

Description:

An important aspect of secure application development is to prevent information leakage. Error messages give an attacker great insight into the inner workings of an application.

The purpose of reviewing the Error Handling code is to assure the application fails safely under all possible error conditions, expected and unexpected. No sensitive information is presented to the user when an error occurs.

When an exception or error is thrown we also need to log this occurrence. Sometimes this is due to bad development, but it can be the result of an attack or some other service your application relies on failing.

All code paths that can cause an exception to be thrown should check for success in order for the exception not to be thrown.

Solution:

We should use a localized description string in every exception, a friendly error reason such as “System Error – Please try again later”. When the user sees an error message, it will be derived from this description string of the exception that was thrown, and never from the exception class which may contain a stack trace, line number where the error occurred, class name or method name.

Do not expose sensitive information in exception messages. Information such as paths on the local file system is considered privileged information; any system internal information should be hidden from the user. As mentioned before an attacker could use this information to gather private user information from the application or components that make up the app.

Don’t put people’s names or any internal contact information in error messages. Don’t put any “human” information, which would lead to a level of familiarity and a social engineering exploit.

Another good example would be for password forget functions to throw a generic error message when a email adress is or is not known on the system. This should prevent enumeration of email adresses.

</details>

___

- [ ] 8.0 Error Handling and Logging Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 8.2.1 Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.
<details><summary>More information</summary>

Include anti caching headers

Description:

Anticaching headers have the ability to tell the browser, computer and proxies what information they may or may not store on the intermediate media

Solution:

These headers are also known as the: Cachecontrol: nostore,nocache and provide protection of sensitive information when implemented in the application or webserver.

Rightly configured anti caching headers will look like the following as a response

Expires: Tue, 03 Jul 2001 06:00:00 GMT
LastModified: {now} GMT
CacheControl: nostore, nocache, mustrevalidate, maxage=0
CacheControl: postcheck=0, precheck=0
Pragma: nocache
</details>

___

- [ ] 8.2.2 Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII.
<details><summary>More information</summary>

Client side storage

Description:

Client side storage also known as Offline Storage or Web Storage. The Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

Solution:

Verify that authenticated data is cleared from client storage, such as the browser DOM, after the session is terminated. This also goes for other session and local storage information which could assist an attacker launching an successful attack.

Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII (personal identifiable information).

</details>

___

- [ ] 8.2.3 Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.
<details><summary>More information</summary>

Client side storage

Description:

Client side storage also known as Offline Storage or Web Storage. The Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

Solution:

Verify that authenticated data is cleared from client storage, such as the browser DOM, after the session is terminated. This also goes for other session and local storage information which could assist an attacker launching an successful attack.

Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII (personal identifiable information).

</details>

___

- [ ] 8.3.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.
<details><summary>More information</summary>

GET POST requests

Description:

Authors of services which use the HTTP protocol SHOULD NOT use GETbased forms for the submission of sensitive data, because this will cause this data to be encoded in the RequestURI. Many existing servers, proxies, and browsers will log the request URL in some place where it might be visible to third parties. Servers can use POSTbased form submission instead. GET parameters are also more likely to be vulnerable to XSS. Please refer to the XSS manual in the knowledge base for more information.

Solution:

Whenever transmitting sensitive data always do this by means of the POST request or by header. Note: Avoid userinput in your application header, this could lead to vulnerabilities. Also make sure you disable all other HTTP request methods which are unnecessary for your applications operation such as; REST, PUT, TRACE, DELETE, OPTIONS, etc, since allowing these request methods could lead to vulnerabilities and injections.

</details>

___

- [ ] 8.3.2 Verify that users have a method to remove or export their data on demand.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 8.3.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.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 8.3.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. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

Key vault

Description:

Keys should remain in a protected key vault at all times. In particular, ensure that there is a gap between the threat vectors that have direct access to the data and the threat vectors that have direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

A key vault helps secure, store and tightly control access to tokens, passwords, certificates and, encryption keys for protecting secrets and other sensitive data.

Imagine the use of a keyvault in the following scenario's

Vault provides encryption as a service with centralized key management to simplify encrypting data in transit and at rest across clouds and datacenters.

a Vault can be used to encrypt/decrypt data that is stored elsewhere. The primary use of this is to allow applications to encrypt their data while still storing it in the primary data store.

The benefit of this is that developers do not need to worry about how to properly encrypt data. The responsibility of encryption is on Vault and the security team managing it, and developers just encrypt/decrypt data as needed.

Solution:

centrally store, access, and distribute secrets like API keys, AWS IAM/STS credentials, SQL/NoSQL databases, X.509 certificates, SSH credentials, etc by means of a key vault.

When selecting a key vault that is fit for your needs make sure it has Cryptographic Compliance towards the FIPS standards.

</details>

___

- [ ] 9.0 Communications Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 9.1.1 Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))
<details><summary>More information</summary>

TLS implementation

Description:

Whenever sensitive information is being sent over the application TLS must be applied in the application to prevent malicious attackers eavesdropping the network can look into and manipulate this sensitive information.

Solution:

Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.

As modern cryptography relies on being computationally expensive to break, specific standards can be set for key sizes that will provide assurance that with today’s technology and understanding, it will take too long to decrypt a message by attempting all possible keys.

Therefore, we need to ensure that both the algorithm and the key size are taken into account when selecting an algorithm. Whenever computer power increases the standards for selecting a new alogrithm changes as well.

</details>

___

- [ ] 9.1.2 Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.
<details><summary>More information</summary>

TLS settings are in line with current leading practice

Description:

TLS settings must always be in line with current leading practice. Whenever TLS settings and ciphers get outdated, the TLS connection can be degraded/broken and used by attackers to eavesdrop on users traffic over the application.

Solution:

There should be structural scans that are done regularly against the applications TLS settings and configurations to check whether the TLS settings are in line with current leading practice.

This could be achieved by using the SSLLabs api or the OWASP OSaft project.

OSaft is an easy to use tool to show informations about SSL certificate and tests the SSL connection according to a given list of ciphers and various SSL configurations.

It's designed to be used by penetration testers, security auditors or server administrators. The idea is to show the important information or the special checks with a simple call of the tool. However, it provides a wide range of options so that it can be used for comprehensive and special checks by experienced people.

While doing these tests also take into consideration the following configuration on the server side:

Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.

</details>

___

- [ ] 9.1.3 Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.
<details><summary>More information</summary>

TLS settings are in line with current leading practice

Description:

TLS settings must always be in line with current leading practice. Whenever TLS settings and ciphers get outdated, the TLS connection can be degraded/broken and used by attackers to eavesdrop on users traffic over the application.

Solution:

There should be structural scans that are done regularly against the applications TLS settings and configurations to check whether the TLS settings are in line with current leading practice.

This could be achieved by using the SSLLabs api or the OWASP OSaft project.

OSaft is an easy to use tool to show informations about SSL certificate and tests the SSL connection according to a given list of ciphers and various SSL configurations.

It's designed to be used by penetration testers, security auditors or server administrators. The idea is to show the important information or the special checks with a simple call of the tool. However, it provides a wide range of options so that it can be used for comprehensive and special checks by experienced people.

While doing these tests also take into consideration the following configuration on the server side:

Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.

</details>

___

- [ ] 10.0 Malicious Code Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 10.3.1 Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 10.3.2 Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.
<details><summary>More information</summary>

code signing

Description: Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity.

Code signing can provide several valuable features. The most common use of code signing is to provide security when deploying; in some programming languages, it can also be used to help prevent namespace conflicts. Almost every code signing implementation will provide some sort of digital signature mechanism to verify the identity of the author or build system, and a checksum to verify that the object has not been modified. It can also be used to provide versioning information about an object or to store other meta data about an objec

Solution: Sign your code and validate the signatures(checksums) of your code and third party components to confirm the integrity of the deployed components.

</details>

___

- [ ] 10.3.3 Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.
<details><summary>More information</summary>

sub domain take over

Description: Subdomain takeover is a process of registering a nonexisting domain name to gain control over another domain. The most common scenario of this process follows:

Domain name (e.g., sub.example.com) uses a CNAME record to another domain (e.g., sub.example.com CNAME anotherdomain.com). At some point in time, anotherdomain.com expires and is available for registration by anyone. Since the CNAME record is not deleted from example.com DNS zone, anyone who registers anotherdomain.com has full control over sub.example.com until the DNS record is present.

The implications of the subdomain takeover can be pretty significant. Using a subdomain takeover, attackers can send phishing emails from the legitimate domain, perform crosssite scripting (XSS), or damage the reputation of the brand which is associated with the domain.

Source: https://0xpatrik.com/subdomaintakeoverbasics/

</details>

___

- [ ] 11.0 Business Logic Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 11.1.1 Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.
<details><summary>More information</summary>

Enforce sequential step order

Description:

Whenever a functionality consists out of following several steps to achieve some goal i.e,

User adds items to chart > User enters shipping information > User pays for goods > Items will be shipped. You want to make sure the user can not skip the payment step in order to receive his goods.

Solution:

In order to verify that this stage was run through by a sincere user you want to enforce the application to only process business logic flows in sequential step order, with all steps being processed in realistic human time, and not process out of order, skipped steps, processed steps from another user, or too quickly submitted transactions.

</details>

___

- [ ] 11.1.2 Verify 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.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 11.1.3 Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 11.1.4 Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 11.1.5 Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modelling or similar methodologies.
<details><summary>More information</summary>

Threat modeling

Description:

Threat modeling is a procedure for optimizing Network/ Application/ Internet Security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.

Solution:

Threat modeling is best applied continuously throughout a software development project. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a highlevel threat model should be defined in the concept or planning phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors are created and exposed. The ongoing threat modeling process should examine, diagnose, and address these threats.

Note that it is a natural part of refining a system for new threats to be exposed. For example, when you select a particular technology such as Java for example you take on the responsibility to identify the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with.

More indepth information about threat modeling can be found at: https://www.owasp.org/index.php/Application_Threat_Modeling

</details>

___

- [ ] 11.1.6 Verify the application does not suffer from "time of check to time of use" (TOCTOU) issues or other race conditions for sensitive operations.
<details><summary>More information</summary>

race conditions

Description: A race condition is a flaw that produces an unexpected result when the timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events. In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled by the framework, server, or programming language.

Solution:

One common solution to prevent race conditions is known as locking. This ensures that at any given time, at most one thread can modify the database. Many databases provide functionality to lock a given row when a thread is accessing it.

</details>

___

- [ ] 11.1.8 Verify the application has configurable alerting when automated attacks or unusual activity is detected.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 12.0 File and Resources Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 12.1.1 Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.
<details><summary>More information</summary>

File upload injections

Description:

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to backend systems, and simple defacement.

There are really two classes of problems here. The first is with the file metadata, like the path and file name. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.

The other class of problem is with the file size or content. An attacker can easily craft a valid image file with PHP code inside.

Solution:

Uploaded files always need to be placed outside the document root of the webserver Check to not accept large files that could fill up storage or cause a denial of service attack Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc Note: when checking these extensions always make sure your application validates the last possible extension so an attacker could not simply inject ".jpg.php" and bypass your validation

Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.

You may also want to check if the filenames do already exist before uploading in order to prevent the overwriting of files.

Also for serving the files back there needs to be a file handler function that can select the file based on an identifier that will serve the file back towards the user.

Most developers also do a mimetype check. This is a good protection however not whenever you are checking this mimetype through the post request. This header can not be trusted since it can be easily manipulated by an attacker.

The best way to check the mimetype is to extract the file from the server after uploading and check it from the file itself. Deleting it whenever it does not comply with expected values.

</details>

___

- [ ] 12.3.1 Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path traversal.
<details><summary>More information</summary>

File upload injections

Description:

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to backend systems, and simple defacement.

There are really two classes of problems here. The first is with the file metadata, like the path and file name. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.

The other class of problem is with the file size or content. An attacker can easily craft a valid image file with PHP code inside.

Solution:

Uploaded files always need to be placed outside the document root of the webserver Check to not accept large files that could fill up storage or cause a denial of service attack Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc Note: when checking these extensions always make sure your application validates the last possible extension so an attacker could not simply inject ".jpg.php" and bypass your validation

Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.

You may also want to check if the filenames do already exist before uploading in order to prevent the overwriting of files.

Also for serving the files back there needs to be a file handler function that can select the file based on an identifier that will serve the file back towards the user.

Most developers also do a mimetype check. This is a good protection however not whenever you are checking this mimetype through the post request. This header can not be trusted since it can be easily manipulated by an attacker.

The best way to check the mimetype is to extract the file from the server after uploading and check it from the file itself. Deleting it whenever it does not comply with expected values.

</details>

___

- [ ] 12.3.2 Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).
<details><summary>More information</summary>

File upload injections

Description:

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to backend systems, and simple defacement.

There are really two classes of problems here. The first is with the file metadata, like the path and file name. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.

The other class of problem is with the file size or content. An attacker can easily craft a valid image file with PHP code inside.

Solution:

Uploaded files always need to be placed outside the document root of the webserver Check to not accept large files that could fill up storage or cause a denial of service attack Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc Note: when checking these extensions always make sure your application validates the last possible extension so an attacker could not simply inject ".jpg.php" and bypass your validation

Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.

You may also want to check if the filenames do already exist before uploading in order to prevent the overwriting of files.

Also for serving the files back there needs to be a file handler function that can select the file based on an identifier that will serve the file back towards the user.

Most developers also do a mimetype check. This is a good protection however not whenever you are checking this mimetype through the post request. This header can not be trusted since it can be easily manipulated by an attacker.

The best way to check the mimetype is to extract the file from the server after uploading and check it from the file itself. Deleting it whenever it does not comply with expected values.

</details>

___

- [ ] 12.3.3 Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI); which may also lead to SSRF.
<details><summary>More information</summary>

File upload injections

Description:

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to backend systems, and simple defacement.

There are really two classes of problems here. The first is with the file metadata, like the path and file name. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.

The other class of problem is with the file size or content. An attacker can easily craft a valid image file with PHP code inside.

Solution:

Uploaded files always need to be placed outside the document root of the webserver Check to not accept large files that could fill up storage or cause a denial of service attack Check the userinput(filename) for having the right allowed extensions such as .jpg, .png etc Note: when checking these extensions always make sure your application validates the last possible extension so an attacker could not simply inject ".jpg.php" and bypass your validation

Check the userinput(filename) for containing possible path traversal patterns in order to prevent him from uploading outside of the intended directory.

You may also want to check if the filenames do already exist before uploading in order to prevent the overwriting of files.

Also for serving the files back there needs to be a file handler function that can select the file based on an identifier that will serve the file back towards the user.

Most developers also do a mimetype check. This is a good protection however not whenever you are checking this mimetype through the post request. This header can not be trusted since it can be easily manipulated by an attacker.

The best way to check the mimetype is to extract the file from the server after uploading and check it from the file itself. Deleting it whenever it does not comply with expected values.

</details>

___

- [ ] 12.3.4 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.
<details><summary>More information</summary>

RFD and file download injections

Description:

Reflective file download occurs whenever an attacker can "forge" a download through misconfiguration in your "disposition" and "content type" headers. Instead of having the attacker to upload an evil file to the web server he can now force the browser to download a malicious file by abusing these headers and setting the file extension to any type he wants.

Now, whenever there is also userinput being reflected back into that download it can be used to forge evil attacks. The attacker can present an evil file to ignorant victim's who are trusting the domain of which the download was presented from.

File download injection is a similar type of attack except this attack is made possible whenever there is userinput that is reflected into the "filename=" parameter in the "disposition" header. The attacker again can force the browser to download a file with his own choice of extension and set the content of this file by injecting this directly into the response like filename=evil.bat%0A%0D%0A%0DinsertEvilStringHere

Whenever the user now opens the downloaded file the attacker can gain full control over the target’s device.

Solution:

First, never use user input directly into your headers since an attacker can now take control over it.

Secondly, you should check if a filename really does exist before presenting it towards the users. You could also create a whitelist of all files which are allowed to be downloaded and terminate requests whenever they do not match.

Also, you should disable the use of "path parameters". It increases the attacker’s attack vector and these parameters also cause a lot of other vulnerabilities. And last you should sanitize and encode all your userinput as much as possible. Reflective file downloads depend on userinput being reflected in the response header. Whenever this input has been sanitized and encoded it should not do any harm to any system it is being executed on

</details>

___

- [ ] 12.3.5 Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.
<details><summary>More information</summary>

File IO commands

Description:

I/O commands allow you to own, use, read from, write to, close devices and To direct I/O operations to a device. Whenever user supplied input i.e file names and/or file data is being directly used in these commands, this could lead to path traversal, local file include, file mime type, and OS command injection vulnerabilities.

Solution:

File names and file contents should be sanitized before being used in I/O commands. 

</details>

___

- [ ] 12.4.1 Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.
<details><summary>More information</summary>

File upload outside document root

Description:

Files that are uploaded by users or other untrusted services should always be placed outside of the document root. This is to prevent malicious files from being parsed by attackers such as PHP/HTML/Javascript files.

Should an attacker succeed to bypass file upload restrictions and upload a malicous file, it would be impossible for the attacker to parse these files since they are not located inside of the applications document root.

Solution:

Files should be stored outside of the applications document root. Preferably files should be stored on a seperate file server which serves back and forth to the application server.

Files should always be stored outside of the scope of the attacker to prevent files from being parsed or executed.

When storing files outside of the document root, take into consideration potential path traversal injections in the applications file name such as "../html/backtoroot/file.php". Whenever this filename is being used directly into the path that is used to store files, it could be used to manipulate the storage path.

</details>

___

- [ ] 12.4.2 Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.
<details><summary>More information</summary>

File upload anti virus check

Description:

whenever files from untrusted services are uploaded to the server, there should be additional checks in place to verify whether these files contain viruses (malware, trojans, ransomware).

Solution:

After uploading the file, the file should be placed in quarantine and antivirus has to inspect the file for malicious viruses. Antivirus software that has a commandline interface is requisite for doing such scans. There are also API's available for other services such as from "VirusTotal.com"

This site provides a free service in which your file is given as input to numerous antivirus products and you receive back a detailed report with the evidence resulting from the scanning process

</details>

___

- [ ] 12.5.1 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.
<details><summary>More information</summary>

Serve files whitelist.

Description:

Configiring the web server to only serve files with an expected file extension helps prevent information leakage whenever developers forget to remove backup files or zipped versions of the web application from the webserver.

Solution:

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.

</details>

___

- [ ] 12.5.2 Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.
<details><summary>More information</summary>

File upload outside document root

Description:

Files that are uploaded by users or other untrusted services should always be placed outside of the document root. This is to prevent malicious files from being parsed by attackers such as PHP/HTML/Javascript files.

Should an attacker succeed to bypass file upload restrictions and upload a malicous file, it would be impossible for the attacker to parse these files since they are not located inside of the applications document root.

Solution:

Files should be stored outside of the applications document root. Preferably files should be stored on a seperate file server which serves back and forth to the application server.

Files should always be stored outside of the scope of the attacker to prevent files from being parsed or executed.

When storing files outside of the document root, take into consideration potential path traversal injections in the applications file name such as "../html/backtoroot/file.php". Whenever this filename is being used directly into the path that is used to store files, it could be used to manipulate the storage path.

</details>

___

- [ ] 12.6.1 Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or load data/files from.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 13.0 API and Web Service Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 13.1.1 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.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 13.1.2 Verify that access to administration and management functions is limited to authorized administrators.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 13.1.3 Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
<details><summary>More information</summary>

Verify that the sensitive information is never disclosed

Description:

Information exposure through query strings in URL is when sensitive data is passed to parameters in the URL. This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data. Simply using HTTPS does not resolve this vulnerability.

Regardless of using encryption, the following URL will expose information in the locations detailed below: https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:

Referer Header Web Logs Shared Systems Browser History Browser Cache Shoulder Surfing

When not using an encrypted channel, all of the above and the following: ManintheMiddle

Solution:

Sensitive informtion should never be included in the URL.

</details>

___

- [ ] 13.2.1 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.
<details><summary>More information</summary>

HTTP request methods

Description:

HTTP offers a number of methods that can be used to perform actions on the web server. Many of these methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. It recommended to read about the different available methods, their purposes and limitations.

Available method are:

GET The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.)[1] The W3C has published guidance principles on this distinction, saying, "Web application design should be informed by the above principles, but also by the relevant limitations.

HEAD The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving metainformation written in response headers, without having to transport the entire content.

POST The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a datahandling process; or an item to add to a database.

PUT The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.

DELETE The DELETE method deletes the specified resource.

TRACE The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.

OPTIONS The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.

CONNECT The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSLencrypted communication (HTTPS) through an unencrypted HTTP proxy.

PATCH The PATCH method applies partial modifications to a resource.

Some of the methods (for example, GET, HEAD, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, web caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe. However, this is not mandated by the standard, and it is explicitly acknowledged that it cannot be guaranteed.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause nontrivial changes on the server. This is discouraged, because it can cause problems for web caching, search engines and other automated agents, which can make unintended changes on the server. For example, a website might allow deletion of a resource through a URL such as http://example.com/article/1234/delete, which, if arbitrarily fetched, even using GET, would simply delete the article.

By contrast, methods such as POST, PUT, DELETE and PATCH are intended for actions that may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers; some that do not conform tend to make requests without regard to context or consequences.

Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time). Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.

In contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may resubmit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.

Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other nonidempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it is not.

The TRACE method can be used as part of a class of attacks known as crosssite tracing; for that reason, common security advice is for it to be disabled in the server configuration. Microsoft IIS supports a proprietary "TRACK" method, which behaves similarly, and which is likewise recommended to be disabled

Solution:

Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST and unused methods are explicitly blocked/disabled.

</details>

___

- [ ] 13.2.2 Verify that JSON schema validation is in place and verified before accepting input.
<details><summary>More information</summary>

JSON validation schema

Description:

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.

When adding schema's to your or JSON files you have better control over what type of userinput can be supplied in your application. This dramatically decreases an attacker’s vector when implemented the right way. Nonetheless, you should always apply your own input validation and rejection as an extra layer of defense. This approach is also desirable since you also want to do countering and logging on the user’s requests and input.

Solution:

Verify that JSON schema validation takes place to ensure a properly formed JSON request, followed by validation of each input field before any processing of that data takes place.

</details>

___

- [ ] 13.2.3 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: triple or double submit cookie pattern (see [references](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)); CSRF nonces, or ORIGIN request header checks.
<details><summary>More information</summary>

CSRF on REST

Description:

CrossSite Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a users Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

The impact of a successful crosssite request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users context. In effect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the targets browser without knowledge of the target user at least until the unauthorized function has been committed.

Solution:

REST (REpresentational State Transfer) is a simple stateless architecture that generally runs over HTTPS/TLS. The REST style emphasizes that interactions between clients and services are enhanced by having a limited number of operations

Since the architecture is stateless, the application should make use of sessions or cookies to store the HTTP sessions, which allow associating information with individual visitors. The preferred method for REST services is to utilize tokens for interactive information interchange between the user and the server.

By sending this information solely by means of headers, the application is no longer susceptible to CSRF attacks since the CSRF attack utilizes the browsers cookie jar for succesful attacks.

</details>

___

- [ ] 13.3.1 Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.
<details><summary>More information</summary>

XML schema (XSD)

Description:

When adding schema's to your or XML files you have better control over what type of userinput can be supplied in your application. This dramatically decreases an attacker’s vector when implemented the right way. Nonetheless, you should always apply your own input validation and rejection as an extra layer of defense. This approach is also desirable since you also want to do countering and logging on the user’s requests and input.

Solution:

Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.

</details>

___

- [ ] 13.3.2 Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.
<details><summary>More information</summary>

Signed message payloads WS security

Description:

In order to establish trust between two communicating party's such as servers and clients there message payload should be signed by means of public/private key method. This builds trust and makes it harder for attackers to impersonate different users.

Web Services Security (WSSecurity, WSS) is an extension to SOAP to apply security to Web services. It is a member of the Web service specifications and was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as Security Assertion Markup Language (SAML), Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide endtoend security.

Solution:

WSSecurity describes three main mechanisms:

How to sign SOAP messages to assure integrity. Signed messages also provide nonrepudiation. How to encrypt SOAP messages to assure confidentiality. How to attach security tokens to ascertain the sender's identity. The specification allows a variety of signature formats, encryption algorithms and multiple trust domains, and is open to various security token models, such as:

X.509 certificates, Kerberos tickets, User ID/Password credentials, SAML Assertions, and customdefined tokens. The token formats and semantics are defined in the associated profile documents.

WSSecurity incorporates security features in the header of a SOAP message, working in the application layer.

These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higherlevel applicationspecific protocols to accommodate a wide variety of security models and security technologies. In general, WSS by itself does not provide any guarantee of security. When implementing and using the framework and syntax, it is up to the implementor to ensure that the result is not vulnerable.

Key management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WSSecurity.

Use cases:

Endtoend security If a SOAP intermediary is required, and the intermediary is not more or less trusted, messages need to be signed and optionally encrypted. This might be the case of an applicationlevel proxy at a network perimeter that will terminate TCP (transmission control protocol) connections.

Nonrepudiation One method for nonrepudiation is to write transactions to an audit trail that is subject to specific security safeguards. Digital signatures, which WSSecurity supports, provide a more direct and verifiable nonrepudiation proof.

Alternative transport bindings Although almost all SOAP services implement HTTP bindings, in theory other bindings such as JMS or SMTP could be used; in this case endtoend security would be required.

Reverse proxy/common security token Even if the web service relies upon transport layer security, it might be required for the service to know about the end user, if the service is relayed by a (HTTP) reverse proxy. A WSS header could be used to convey the end user's token, vouched for by the reverse proxy.

</details>

___

- [ ] 14.0 Configuration Verification Requirements
<details><summary>More information</summary>

</details>

___

- [ ] 14.2.1 Verify that all components are up to date, preferably using a dependency checker during build or compile time.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 14.2.2 Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.
<details><summary>More information</summary>

insecure application defaults

Description:

When default sample applications, default users, etc are not removed from your production environment you are increasing an attackers potentiall attack surface significantly.

Solution:

Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.

</details>

___

- [ ] 14.2.3 Verify that if application assets, such as JavaScript libraries, CSS stylesheets 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.
<details><summary>More information</summary>

Application assets hosted on secure location

Description:

Whenever application assets such as JavaScript libraries or CSS styleshees are not hosted on the application itself but on a external CDN which is not under your control these CDNs' can introduce security vulnerabilities. Whenever one of these CDN gets compromised attackers can include malicious scripts. Also whenever one of these CDNs' get out of service it could affect the operation of the application and even cause a denial of service.

Solution:

Verify that all application assets are hosted by the application, such as JavaScript libraries, CSS stylesheets and web fonts are hosted by the application rather than rely on a CDN or external provider. 

</details>

___

- [ ] 14.3.1 Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 14.3.2 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.
<details><summary>More information</summary>

Debug enabeling

Description:

Sometimes it is possible through an "enabling debug parameter" to display technical information/secrets within the application. As a result, the attacker learns more about the operation of the application, increasing his attack surface. Sometimes having a debug flag enabled could even lead to code execution attacks (older versions of werkzeug)

Solution:

Disable the possibility to enable debug information on a live environment.

</details>

___

- [ ] 14.3.3 Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
<details><summary>More information</summary>

Verbose version information

Description:

Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.

Solution:

Verify that the HTTP headers do not expose detailed version information of system components. For each different type of server, there are hardening guides dedicated especially for this type of data leaking. The same applies for i.e any other leak of version information such as the version of your programming language or other services running to make your application function.

</details>

___

- [ ] 14.4.1 Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).
<details><summary>More information</summary>

Content type headers

Description:

Setting the right content headers is important for hardening your applications security, this reduces exposure to driveby download attacks or sites serving user uploaded content that, by clever naming could be treated by MS Internet Explorer as executable or dynamic HTML files and thus can lead to security vulnerabilities.

Solution:

An example of a content type header would be: 

ContentType: text/html; charset=UTF8
or:
ContentType: application/json;

Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).

</details>

___

- [ ] 14.4.2 Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type).
<details><summary>More information</summary>

API resonses security headers

Description:

There are some security headers which should be properly configured in order to protect some API callbacks against Reflective File Download and other type of injections.

Also check if the API response is dynamic, if user input is reflected in the response. If so, you must validate and encode the input, in order to prevent XSS and Same origin method execution attacks.

Solution:

Sanitize your API's input (in this case they should just allow alphanumeric); escaping is not sufficient

Verify that all API responses contain XContentTypeOptions: nosniff, to prevent the browser from interpreting files as something else than declared by the content type (this helps prevent XSS if the page is interpreted as html or js).

Add 'ContentDisposition: attachment; filename="filename.extension"' with extension corresponding the file extension and contenttype, on APIs that are not going to be rendered

</details>

___

- [ ] 14.4.3 Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.
<details><summary>More information</summary>

Content security policy headers

Description:

The main use of the content security policy header is to, detect, report, and reject XSS attacks. The core issue in relation to XSS attacks is the browser's inability to distinguish between a script that's intended to be part of your application, and a script that's been maliciously injected by a thirdparty. With the use of CSP(Content Security policy), we can tell the browser which script is safe to execute and which scripts are most likely been injected by an attacker.

Solution:

A best practice for implementing CSP in your application would be to externalize all JavaScript within the web pages.

So this:

    <script>
      function doSomething() {
        alert('Something!');
      }
    </script>

    <button onclick='doSomething();'>foobar!</button>

Must become this:

    <script src='doSomething.js'></script>
    <button id='somethingToDo'>Let's foobar!</button>

The header for this code could look something like:

    ContentSecurityPolicy: defaultsrc'self'; objectsrc'none'; scriptsrc'https://mycdn.com'

Since it is not entirely realistic to implement all JavaScript on external pages we can apply sort of a crosssite request forgery token to your inline JavaScript. This way the browser can again distinguish the difference between code which is part of the application against probable malicious injected code, in CSP this is called the 'nonce'. Of course, this method is also very applicable on your existing code and designs. Now, to use this nonce you have to supply your inline script tags with the nonce attribute. Firstly, it's important that the nonce changes for each response. Otherwise, the nonce would become guessable. So it should also contain a high entropy and should be hard to predict. Similar to the operation of the CSRF tokens, the nonce becomes impossible for the attacker to predict making it difficult to execute a successful XSS attack.

Inline JavaScript example containing nonce:

    <script nonce=sfsdf03nceI23wlsgle9h3sdd21>
    <! Your javscript code >
    </script>

Matching header example:

    ContentSecurityPolicy: scriptsrc 'noncesfsdf03nceI23wlsgle9h3sdd21'

There is a whole lot more to learn about the CSP header for indepth implementation in your application. This knowledge base item just scratches the surface and it would be highly recommended to gain more indepth knowledge about this powerful header

Very Important: When applying the CSP header, although it blocks XSS attacks. Your application still remains vulnerable to HTML and other code injections. So this is not a substitute for, validation, sanitizing and encoding of userinput.

</details>

___

- [ ] 14.4.4 Verify that all responses contain X-Content-Type-Options: nosniff.
<details><summary>More information</summary>

API resonses security headers

Description:

There are some security headers which should be properly configured in order to protect some API callbacks against Reflective File Download and other type of injections.

Also check if the API response is dynamic, if user input is reflected in the response. If so, you must validate and encode the input, in order to prevent XSS and Same origin method execution attacks.

Solution:

Sanitize your API's input (in this case they should just allow alphanumeric); escaping is not sufficient

Verify that all API responses contain XContentTypeOptions: nosniff, to prevent the browser from interpreting files as something else than declared by the content type (this helps prevent XSS if the page is interpreted as html or js).

Add 'ContentDisposition: attachment; filename="filename.extension"' with extension corresponding the file extension and contenttype, on APIs that are not going to be rendered

</details>

___

- [ ] 14.4.5 Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.
<details><summary>More information</summary>

HTTP strict transport security

Description:

HTTP Strict Transport Security (HSTS) is an optin security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.

HSTS addresses the following threats:

  1. User bookmarks or manually types http://example.com and is subject to a maninthemiddle attacker HSTS automatically redirects HTTP requests to HTTPS for the target domain
  2. Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP HSTS automatically redirects HTTP requests to HTTPS for the target domain
  3. A maninthemiddle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate

  4. HSTS does not allow a user to override the invalid certificate message

    Solution:

When users are visiting the application it should set the following header: These headers should be set in a base class which always sets the header no mather what page the users initially visit.

Simple example, using a long (1 year) maxage: StrictTransportSecurity: maxage=31536000

If all present and future subdomains will be HTTPS: StrictTransportSecurity: maxage=31536000; includeSubDomains

CAUTION: Site owners can use HSTS to identify users without cookies. This can lead to a significant privacy leak.

Cookies can be manipulated from subdomains, so omitting the include "includeSubDomains" option permits a broad range of cookierelated attacks that HSTS would otherwise prevent by requiring a valid certificate for a subdomain. Ensuring the "Secure Flag" is set on all cookies will also prevent, some, but not all, of the same attacks.

</details>

___

- [ ] 14.4.6 Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin".
<details><summary>More information</summary>

Referrer policy header

Description: Requests made from a document, and for navigations away from that document are associated with a Referer header. While the header can be suppressed for links with the noreferrer link type, authors might wish to control the Referer header more directly for a number of reasons,

Privacy A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user’s profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).

Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user’s profile contained the links.

Security A web application uses HTTPS and a URLbased session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user’s session identifier in the URL.

Alternatively, a web application may use URLs which themselves grant some capability. Controlling the referrer can help prevent these capability URLs from leaking via referrer headers.

Note that there are other ways for capability URLs to leak, and controlling the referrer is not enough to control all those potential leaks.

Trackback A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive trackback links.

Solution:

For more information about the policy and how it should be implemented please visit the following link,

https://www.w3.org/TR/referrerpolicy/referrerpolicies

</details>

___

- [ ] 14.4.7 Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use for sites where content should not be embedded in a third-party site.
<details><summary>More information</summary>

Include anti clickjacking headers

Description:

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

Solution:

To avoid your application from being clickjacked you can add the XframeOptions header to your application. These headers can be configured as:

XframeOptions: deny

The page cannot be displayed in a frame, regardless of the site attempting to do so.

XFrameOptions: sameorign

The page can only be displayed in a frame on the same origin as the page itself.

XFrameOptions: ALLOWFROM uri

The page can only be displayed in a frame on the specified origin.

You may also want to consider to include "Framebreaking/Framebusting" defense for legacy browsers that do not support XFrameOption headers.

Source: https://www.codemagi.com/blog/post/194

</details>

___

- [ ] 14.5.1 Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.
<details><summary>More information</summary>

HTTP request methods

Description:

HTTP offers a number of methods that can be used to perform actions on the web server. Many of these methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. It recommended to read about the different available methods, their purposes and limitations.

Available method are:

GET The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.)[1] The W3C has published guidance principles on this distinction, saying, "Web application design should be informed by the above principles, but also by the relevant limitations.

HEAD The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving metainformation written in response headers, without having to transport the entire content.

POST The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a datahandling process; or an item to add to a database.

PUT The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.

DELETE The DELETE method deletes the specified resource.

TRACE The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.

OPTIONS The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.

CONNECT The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSLencrypted communication (HTTPS) through an unencrypted HTTP proxy.

PATCH The PATCH method applies partial modifications to a resource.

Some of the methods (for example, GET, HEAD, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, web caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe. However, this is not mandated by the standard, and it is explicitly acknowledged that it cannot be guaranteed.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause nontrivial changes on the server. This is discouraged, because it can cause problems for web caching, search engines and other automated agents, which can make unintended changes on the server. For example, a website might allow deletion of a resource through a URL such as http://example.com/article/1234/delete, which, if arbitrarily fetched, even using GET, would simply delete the article.

By contrast, methods such as POST, PUT, DELETE and PATCH are intended for actions that may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers; some that do not conform tend to make requests without regard to context or consequences.

Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time). Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.

In contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may resubmit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.

Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other nonidempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it is not.

The TRACE method can be used as part of a class of attacks known as crosssite tracing; for that reason, common security advice is for it to be disabled in the server configuration. Microsoft IIS supports a proprietary "TRACK" method, which behaves similarly, and which is likewise recommended to be disabled

Solution:

Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST and unused methods are explicitly blocked/disabled.

</details>

___

- [ ] 14.5.2 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.
<details><summary>More information</summary>

not available item

Description:

This item is currently not available.

Solution:

This item is currently not available.

</details>

___

- [ ] 14.5.3 Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to match against and does not support the "null" origin.
<details><summary>More information</summary>

Cross origin resource sharing

Description:

Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform 'crossdomain' requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy.

Solution:

CrossOrigin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use a web browser and a server to determine whether a crossorigin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers:

Origin AccessControlRequestMethod AccessControlRequestHeaders AccessControlAllowOrigin AccessControlAllowCredentials AccessControlAllowMethods AccessControlAllowHeaders

Things you must consider when using CORS

  1. Validate URLs passed to XMLHttpRequest.open. Current browsers allow these URLs to be cross domain; this behavior can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.

  2. Ensure that URLs responding with AccessControlAllowOrigin: * do not include any sensitive content or information that might aid an attacker in further attacks. Use the AccessControlAllowOrigin header only on chosen URLs that need to be accessed crossdomain. Don't use the header for the whole domain.

  3. Allow only selected, trusted domains in the AccessControlAllowOrigin header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use * wildcard nor blindly return the Origin header content without any checks)

  4. Keep in mind that CORS does not prevent the requested data from going to an unauthenticated location. It's still important for the server to perform usual CSRF prevention.

  5. While the RFC recommends a preflight request with the OPTIONS verb, current implementations might not perform this request, so it's important that "ordinary" (GET and POST) requests perform any access control necessary.

  6. Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.

  7. Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests, but may be spoofed outside the browser. Applicationlevel protocols should be used to protect sensitive data.

NOTE: Modern application frameworks do dynamically allocation of the origin header, resulting in the browser also allowing to send the "AccessControlAllowCredentials: true" header as well in requests. Whenever JSON web tokens are being send in cookies rather than headers, potential attackers could abuse this behaviour to make unauthenticated XHR get requests on the authenticated users behalf to read sensitive information from the pages.


</details>