Security

OWASP

HTTPS

Wikipedia HTTPS

IBM overview of SSL or TLS handshake

Provides secure communication over the internet using Transport Layer Security (TLS) or Secure Sockets Layer (SSL). HTTPS provides authentication of the website and web server, which ensures a client is communicating with who they believe they are communicating with (see man-in-the-middle attack). It also provides bidirectional encryption, preventing eavesdropping and tampering of communication.

Handshake steps:

1. Client sends "client hello" with information about what kind of encryption it can handle.
2. Server sends "server hello" with with chosen encryption process and its digital certificate, issued by a Certification Authority (CA).
3. Client will check that certificate is indeed issue by a CA (browsers maintain a list of trusted CAs).
4. Client uses public key contained in certificate to encrypt a proposed shared key and sends it to server.
5. Server decodes proposed shared key using its private key (which lives safely and exclusively on the server).
6. Both now have symmetric key for communicating securely.

XSS Attack

OWASP Cross-site scripting attack

Cross-site Scripting (XSS) attacks occur when a malicious script is inserted into a web site. For example, if input is allowed by a user which will then be displayed to other users, such as a comments section of a web forum, and the displayed input is neither sanitized nor escaped, then it would be vulnerable. A user could therefore submit script tags containing malicious JavaScript, Flash, HTML, or any other code that a browser can execute. Such code can transmit cookies, localStorage, or other session information, redirect the victim to content controlled by the attack, or run various other operations on the victim's machine.

Rules for preventing XSS:

1. Escape untrusted data before adding it to the HTML body: be sure to also escape characters that will allow switching to an execution context (script, style, or event handlers). Use hex entities.
2. Escape untrusted data before inserting it into common attributes: This is for attributes such as width, name, value, etc.
3. Escape untrusted data into JavaScript data values: This is for script blocks and event-handler attributes. Only place untrusted data into a quoted "data value."
   1. Rule 3.1 Escape JSON values in an HTML context and read the data with JSON.parse
4. Escape and strictly validate untrusted data before inserting into CSS or style property values: CSS can be used for attacks. Never allow urls in CSS to start with 'javascript' or 'expression', even when they're escaped.
5. Escape untrusted data before inserting it into HTML URL parameter values
6. Sanitize HTML markup using a library: If you application must render HTML submitted by users, use a library like SanitizeHelper for Rails or Bleach of JavaScript to sanitize it.
7. Prevent DOM-based XSS: This is a special type of XSS attack and requires a separate set of steps to prevent

CSRF Attack

OWASP Cross-site Request Forgery

Cross-site Request Forgery (CSRF) is an attack that causes its victim to execute an action on a web application for which they are currently authenticated. For example, an attacker could trick a victim into submitting a form to a web server using cookies on the victim's browser which contain authenticating information. The form could then transfer funds, change the victim's email address and password, purchase an item, or various other malicious actions.

Prevention:

You'll regularly want to deliberately allow cross origin requests (CORS). If your server is hosted separately from your client (you have a Node/Django/Rails/Go etc. api feeding a React/Angular/Vue/Backbone etc. front end), then you should use a CORS library that allows you to specify which origins to allow requests from. If both are served from the same origin, do the following:

1. Check headers to verify the request is the source origin and the target origin are the same.
2. Ensure that a valid CSRF token is present in the request. This is a cryptographically secure random token that the server will generate and attach to a form that is specific to the user.

Password Protection

Stackoverflow authentication answer

Passwords should never be stored as paintext. If a database containing user password information is leaked, the attacker will have instant access to not just all of the users' accounts, but since many people use the same passwords for multiple services, they'll likely have access to those accounts as well. Therefore, it is important to use one way cryptographic hashing functions (such as bcrypt, scrypt, or Argon2) to obfuscate the password. Any time someone tries to log in, their password will be passed through the same function and and can be compared with the hashed version that was saved when they signed up. If an attacker is able to obtain those encrypted passwords, they will not be able to reverse them (ie get the plain text password) and use the passwords elsewhere.

However, attackers can use a dictionary of likely passwords to create a rainbow table. Such a table will pass all of those likely passwords through the hashing algorithm, and then use that table to compare against the database of leaked credentials. Everyone using a common password will therefore have their password revealed. To help prevent this, it is important to use a salt in conjunction with the hashing function. A salt is a random piece of data that is generated for every password and added to it before it gets hashed. It will make the same plaintext password have two completely different hash values, thus forcing any rainbow table to be much larger.

Even if attackers don't have access to hashed passwords, they can still get into users' accounts. They can use brute force attacks to simply try to log in over and over again for a particular user through your normal UI in a process that can be automated. CAPTCHAs are designed to prevent this, but you can also use software that will throttle an IP address, limiting the number to HTTP requests they can make over a period of time. An attacker can get around this as well too by distributing attacks across many IP addresses. And instead of trying to access one account using many common passwords (which could lock that account), they may try to access every account using the one or two most common passwords. You can prevent this by throttling all account logins if you experience an unusually large number of attempts over a given period.

Weak passwords will be simple to crack no matter what. It may be advisable to simply not use passwords at all and consider other alternatives. If you must use passwords, the current consensus is to encourage or require user select long passwords that are several common but random words: xkcd.