Same origin policy

By | Terminology | No Comments

An origin is defined as a combination of URI scheme, host name, and port number. Same Origin Policy prevents a web site’s scripts from accessing and interacting with scripts used on other sites. In other words, this policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s Document Object Model.

Cross-Origin Resource Sharing

The second technique for relaxing the same-origin policy is standardized under the name Cross-Origin Resource Sharing. This standard extends HTTP with a new Origin request header and a new Access-Control-Allow-Origin response header. It allows servers to use a header to explicitly list origins that may request a file or to use a wildcard and allow a file to be requested by any site.

Read more: Why is the same origin policy important?

Cross-site Scripting (XSS)

By | Terminology | No Comments

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)

By | Terminology | No Comments

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.


Πολιτικές για ασφαλείς κωδικούς

By | Policies | No Comments

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