Security course 30 April 2018

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;

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

Authentication

1. User IDs - users must be unique. No shared 'office admin' accounts with naff passwords.
2. Don't use shit passwords. Enforce minimum password complexity, use multi-factor auth, biometrics, etc.
3. Encrypt user authentication data over the network (including database connections).
4. Don't store passwords in clear text.
5. Password management policies - e.g. time-out or reset request after x attempts, lock account after y attempts.
6. 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:

1. User logins.
2. Privileged operations e.g. create new user, role/permissions changes, etc.
3. failed attempts to elevate privileges.
4. failed attempts to access files, functions, services. (Was it temporarily down, or was it attacked?)
5. 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

1. Use appropriate URL encoding (/ = %2f) and HTML encoding (& = &)
2. 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 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

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

Telling browsers not to cache input field values: autocomplete="off" 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

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

Prevention

1. Use encryption!
2. Use strong encryption!
3. Use ACLs!
4. Delete temporary or ephemeral data, and data that's no longer required. Don't cache sensitive data on the client.
5. 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).