Cross-site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
Non-persistent XSS: These are usually the most common types. Typically these are within HTTP query parameters and are used by server-side scripts to parse and display a page of results for the user.
Persistent XSS: These are when the data from the attacker is actually saved on the server and then displayed to the user, mimicking a normal page.

Read more: OWASP – XSS, X-XSS-Protection

Cross-Site Request Forgery (CSRF)

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.


HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is an opt-in 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.

Read more: OWASP – HSTS Cheatsheet,

Password policies

Responsibilities of systems processing passwords

– Passwords must be prohibited from being displayed when entered.
– Passwords must never be stored in clear, readable format (encryption must always be used).
– Encrypted password hashes must never be accessible to unauthorized individuals.
– Where possible, salted hashes should be used for password encryption.

Password requirements

– At least eight (8) characters; using a combination of at least one character from each of the following four listed character types:
— uppercase letters (A-Z)
— lowercase letters (a-z)
— base 10 digits (0-9)
— non-alphanumeric (such as ` ~ ! @ # $ % ^ & * ( ) _ + – = { } | \ : ” ; ‘ < > ? , . / and space)
– Passwords should not match the username, or parts of the user’s full name, such as their first name.

Password Aging

– Passwords must be changed every ‘X’ months, where ‘X’ can be 6 months.
– At least four (4) characters must be changed when new passwords are created.
– New passwords must comply with the password requirements defined in the previous section.

** For admin users enforce a more strict password policy.

Read more: Password policies and guidelines, Password policies and best practices , Configuring Password Policies


Useful links

OWASP top 10 – 2017