View source for Security course 30 April 2018

__NOTOC__
;ACL: Access Control List.
;Access Control: who can access which parts of a system, by assigning permissions to roles, users to groups, and roles to groups.
;Authentication: confirmation of identity.
;Authorisation: access control.
;NZISS: New Zealand Internet Security Standard

Restrict database access to only the tables required, use a minimum of stored procedures to hide sensitive tables entirely (e.g. an AUTHENTICATE() stored procedure, and no access to the USER table.

 CREATE FUNCTION AUTHENTICATE(u TEXT, p TEXT) RETURNS TABLE (username TEXT, property1, TEXT, ...) AS $$
 BEGIN
   SELECT username, property1, ... FROM users WHERE username = u, password = CRYPT(p);
 END;
 $$ LANGUAGE plpgsql;

# Design software to use the lowest privilege level required to complete its tasks.
# Deny access by default.
# Check return values of all system calls.
# Validate all inputs - lengths, field types, ranges, controlled vocabularies.

== Authentication ==

# User IDs - users must be unique. No shared 'office admin' accounts with naff passwords.
# Don't use shit passwords. Enforce minimum password complexity, use multi-factor auth, biometrics, etc.
# Encrypt user authentication data over the network (including database connections).
# Don't store passwords in clear text.
# Password management policies - e.g. time-out or reset request after x attempts, lock account after y attempts.
# Display when a user last logged in.

== Auditing ==

Log at least these events. We need who did what, where (source IP, device ID, etc.), and when:

# User logins.
# Privileged operations e.g. create new user, role/permissions changes, etc.
# failed attempts to elevate privileges.
# failed attempts to access files, functions, services. (Was it temporarily down, or was it attacked?)
# Security-related alerts and failures.

DON'T IMPLEMENT YOUR OWN CRYPTO unless you are a professional cryptologist implementing a software cryptography library.

== Input handling ==

Never trust anything passed in, including the URL and its parameters, HTML form data, cookie values, request headers, without validating/sanitising them.

== Output handling ==

# Use appropriate URL encoding (/ = %2f) and HTML encoding (& = &amp;)
# Use HTTPS Strict Transport Security, Content Security Policy, and HTML frame options.

== OWASP ==

Open Web Application Security Project. Freely available information, cheat sheets and guidelines, including:

* The [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten].
* Secure Coding Quick Reference Guide
* Zed Attack Proxy (ZAP)

=== Injection ===

Not just SQL. NoSQL, XML, serialisation, etc. Routers sometimes let you inject shell commands. Havoc ensues:
 ping $input
Allows for 
 google.com; cat /etc/passwd

=== Broken Authentication ===

Credentials not protected when stored or transmitted, or can be guessed, or overwritten. Fun with badly handled session IDs, exposed in URLs, stored plain-text in cookies, not regenerated after login, not expired on logout. Timing attack on authentication queries and other requests can give a true/false verification and can figure out database structure (e.g. true takes longer, false fails immediately), etc.

==== Prevention ====

# Don't reinvent your wheels, use a well-supported mature web framework to handle auth/authz, sessions, etc.
# Use multi-factor authentication.
# Disable default accounts, change default passwords.
# Use a sensible password policy. Check for weak/naff passwords, show a strength indicator.
# Limit or tar-pit failed auth attempts.
# Detect/prevent account enumeration attacks on account profile, registration, recovery pages.
# Use random/hashed session IDs, use 'secure' and 'httpOnly' session cookies.
# HTTPS by default everywhere. With free LetsEncrypt certificates there's very little excuse in 2018.

Telling browsers not to cache input field values: <tt>autocomplete="off"</tt> great for card details, but in a password field, blocks password managers. So HTML5 allows password managers to override page instructions, so browsers started ignoring autocomplete for password fields.

=== Sensitive data exposure ===

# Transmitted in clear-text over a network.
# Old or weak ciphers, in light of Moore's law.
# Improper leakage through incorrect ACLs or authorisation.
# Not encrypted in storage, database, on disk.

==== Prevention ====

# Use encryption!
#* Use the Mozilla [https://mozilla.github.io/server-side-tls/ssl-config-generator/ SSL configuration generator]
# Use strong encryption!
# Use ACLs!
# Delete temporary or ephemeral data, and data that's no longer required. Don't cache sensitive data on the client.
# Safely store and handle encryption keys.

==== Government approved cryptography ====

* Symmetric algo: AES, minimum 256 bit keys.
* Hashing algo: SHA2, 256, 384, 512 bits.
* Asymmetric PK algo: Elliptic Curve Diffie-Hellman (ECDH), Elliptic Curve Digital Signature Algorithm (ECDSA).