Jon's Wiki
Security course 30 April 2018

Security course 30 April 2018

From Jon's Wiki
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() and GET_PROFILE() stored procedures, 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 = DIGEST(p, 'SHA256');
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)

A1: 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

A2: 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.

A3: 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!
    • Click "modern"
  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).

A4: XML External Entities (XXE)

XML allows you to define your own entities: 

<!ENTITY [%] name [] ... >

Most XML parsing libraries are now sensibly configured not to do this sort of crazy advanced shit that nobody really uses anyway, for example: 

<!ENTITY xxe "file:///etc/passwd">
&xxe;

The Billion LOLZ attack will make any mis-configured server go dark: 

<!ENTITY lol0 "LOL">
<!ENTITY lol1 "&lol0;&lol0;&lol0;&lol0;&lol0;&lol0;&lol0;&lol0;&lol0;&lol0;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 ... etc.
&lol9

Anything that uses SOAP, SAML, or any other XML APIs are potentially vulnerable.

Prevention

  1. Don't use XML! Use something simpler that only has keys and values, e.g. JSON.
  2. Use a well-supported, standard XML parsing library, keep it up to date
  3. disable the advanced DTD and ENTITY "features" by default.
  4. Use whitelist input validation on the XML data, use XSD validation

A5: Broken Access Control

  1. (A4 insecure direct object references) e.g. access to an uploaded file, or REST API URL, without auth/authz, e.g. press releases under embargo.
  2. (A7 Missing Functional Level Access Control). e.g. URL diecovery, enumerating objects by URL - e.g.:
    • /invoices/12345
    • /users/123/profile
    • /getfile?file=../../../../etc/passwd
    • /set_salary?employee=1234&salary=1,000,000

Prevention

  1. Always perform access control checks for each request (use a web framework!)
  2. ACL must be performed on the server, never rely on the client.
  3. Perform ACL checks using only data the user can't tamper with.
  4. Don't use traversable direct references - use per user or per session refs, or UUIDs instead.

A6: Security Misconfiguration

Can happen all over the place up and down the stack, from the server filesystem to the browser-side JavaScript.

Prevention

Approved, defined configuration hardening. Turn everything off by default, in production only install what is necessary and being used. Disable stack traces, debug options, and verbose logging in production (and production-like) environments. Use scanning tools, e.g. OpenVAS, Nessus, Qualys, nmap etc.

A7: Cross-Site Scripting (XSS)

When an app displays unfiltered user-supplied data on an HTML page. Hijacking user session or the browser, to access other things on the PC, or just defacing (pwnd) websites. Can be stored (into the database) or just reflected (when a form is submitted and displayed). Very simply, adding this to an form postal address field: 

<script>alert(document.cookie);</script>

Prevention

  1. Input validation
  2. Escape and encode all input
  3. Filter all output
  4. Use a Content Security Policy HTTP header.
# Example WordPress E-Commerce site:
Content-Security-Policy: default-src: self; style-src: self; connect-src: https://api.stripe.com; \
      frame-src self https://js.stripe.com; script-src self https://js.stripe.com
Retrieved from "https://wiki.jon.geek.nz/index.php?title=Security_course_30_April_2018&oldid=2224"