1 minute, 36 seconds

I recently documented best security practices for writing a web app. Since I was most of the way there for a nice tidy blog post on the topic, I’m using the contents of those docs as a cheat sheet for web app security. Best to refer to OWASP for a more exhaustive list, but here’s mine in PHP/Apache:

title	description	sample
No Traffic on Port 80	Always use an encrypted channel for web traffic, never send a session cookie in the clear	RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
HSTS	Set header so after 1st redirect, client goes directly to SSL connection	Header always set Strict-Transport-Security “max-age=15768000”
Forward Secrecy	Use ephemeral keys for TLS connections to prevent wholesale decryption if private key is compromised	SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH SSLProtocol All -SSLv2 -SSLv3 SSLHonorCipherOrder On
Anti-Clickjacking	Prevent your site from being included in an iframe	Header always set X-Frame-Options DENY
Anti-CSRF Nonces	No one getting tricked to submit pre-filled forms using their existing session cookie	$_POST[$NONCEKEY] == $_COOKIE[$NONCEKEY] (but more to it – see this gist)
XSS escaping	NEVER TRUST USER INPUT, save raw values to DB, cleanse on display	print htmlspecialchars($user_string_here, ENT_QUOTES, ‘UTF-8’)
Secure cookies	Never transmit cookies in the clear, works well with HSTS	setcookie( ‘session’, $sessionId, 0, ‘/’, ‘www.example.com’, isset($_SERVER[“HTTPS”]), true);
HttpOnly cookies	don’t allow JavaScript/XSS to access your cookies	setcookie( ‘session’, $sessionId, 0, ‘/’, ‘www.example.com’, isset($_SERVER[“HTTPS”]), true);
bcrypt hashes	Use a *slow* hashing method instead of a *fast* one (I’m looking at you MD5…)	password_hash(“rasmuslerdorf”, PASSWORD_DEFAULT) Though Argon2 is up and coming!
strong session ID	don’t store anything but pseudo random ID in the cookie. Again NEVER TRUST USER INPUT!	bin2hex(openssl_random_pseudo_bytes(50))
no session fixation	on logout, delete cookie **and** server side entry in DB so session is dead dead dead	NA
re-prompt for passwords	on email, password or username change or when showing/changing sensitive data	NA
no SQL injection	still NEVER TRUST USER INPUT, parameterize all queries	$dbh = new PDO(…); $stmt = $dbh->prepare(‘SELECT * FROM users where username = :username’); $stmt->execute( array(‘:username’ => $_REQUEST[‘username’]) );

1 minute, 56 seconds

I was working on implemented a nonce to fight CSRF requests on all our forms. The nonce worked liked you expect: by setting a cookie and then putting the same value in the form. When the form was submitted, the back end checked that the form nonce matched the cookie nonce and, bam, bob is your uncle.

The HTML for the form was hosted on foo.domain.com and was fetched via an AJAX call to render it in a modal on bar.domain.com. It used a JavaScript function that looked like this:

  $('.login_action').click(function(){
    Modal.init({
      id: "login",
      primary_button_action: function(){
        $('form #loginform').submit();
      },
      url: URL_ROOT + "modal/login",
    }).open();
  });

Now, you can’t quite tell, but this is ultimately a wrapper for Twitter’s Bootstrap’s Modal call:

$('#login').modal(options)

For the life of me I could not figure out when the AJAX call from foo subdomain to bar subdomain was not setting the nonce cookie. I thought it would be a CORS issue, but quickly dismissed that because we all know that “AJAX Requests Get And Set Cookies Like Any Other HTTP Request“, right. RIGHT?!!?

I did follow the best practice of putting in poor man’s PHP break points to trace the $_POST and $_COOKIE values, but to no avail.

After far too long, but after a healthy discussion with a friend about how we learn and how we trouble shoot, I remembered my mantra I always tell junior engineers: “Simplify the problem! Distill it down. Ideally, continue to cut the code in half again and again until just the bare minimum manifesting the problem remains.”

This lead me to reproduce the problem in two lines of code on foo.domain.com to call bar.domain.com:

The problem was still there! No nonce cookies getting set. Let’s remove jQuery then and go to raw JS requests:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://bar.domain.com', true);
xhr.withCredentials = true;
xhr.send();

Wait ah second! What was that I see in the console?!@@!#%$:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bar.domain.com. (Reason: CORS header 'Access-Control-Allow-Origin' does not match '*').

Oh…CORS…the thing I dismissed upfront. So, yes, AJAX calls are just HTTP requests per bennadel.com’s blog post, but of course if foo subdomain is calling the modal on bar subdomain via AJAX, it’s an XHR request to another (sub)domain which needs to play by CORS rules.

If any one is interested, I published a gist with our PHP code to do nonces.