Simple Principles for Website Security

Langara Computer Tech Meetup
February 21, 2014

Simple Principles for Website Security
Lauren Wood
lauren@textuality.com
slideshare.net/laurendw

Licensed under a Creative Commons
Attribution-Noncommercial-Share Alike 3.0 Unported License

1

Contents

Basics of HTTP and HTTPS
Some common security attacks
Protecting your site
Protecting yourself


2

HTTP and HTTPS

Licensed under a Creative Commons Attribution-NoncommercialShare Alike 3.0 Unported License

HTTP Flows
Core HTTP protocol

•
•

Client requests a resource with certain parameters (headers)
Ideally the server responds with the requested resource,
and/or a status code and headers

Client

GET /index.html HTTP/1.1
+ headers

Server

200 OK + headers +
index.html


4

HTTP Basic Authentication
Basic authentication - HTTP 1.0, 1999, RFC 2617

•
•
•

widely implemented
not secure, password sent in clear text
protects resources in authentication realm
GET /index.html HTTP/1.1
+ headers

Client

401 unauthorized

Server

username + password
resource + headers

5

HTTP Digest Authentication

•
•
•
•

Encrypts the password using cryptographic hash aka digest

•

Easier to implement/use HTTP Basic over SSL/TLS than HTTP
Digest

Cryptographic hash is effectively impossible to break
Quick to compute the digest from the string
Security further improved by using a nonce (random number,
generated on server, that changes each time the client gets the
401)


6

Summary: HTTP Authentication
Based on password authentication

•
•
•
•
•
•
•

weak authentication (only one factor)
people tend to forget their passwords
solutions to forgetting often not secure
easy to implement
suitable for “don't need much protection” resources
Digest more secure but harder to use
Use Basic over SSL for reasonable security


7

Data protection (security)


Connection-based security
Secures the path between two end-points.
Security is transient, only for the data in motion.
Relatively simple to use, high performance.
Point to point solution, doesn’t work across middle
points.


9

HTTPS/TLS/SSL
Adds encryption, signing, records, and session
tracking to the basic HTTP

•

browser sends request to port 443 with session ID, encryption
algorithms it likes, random string, and requested website

•

web site sends back server name, session ID, encryption
algorithm, server version of the string, and server certificate

•

browser decides whether to trust the certificate, checks the
host name

•
•

exchange tokens (secrets) to encrypt the data
start exchanging encrypted data with session IDs and
sequence numbers


10

What is a Certificate?

•
•
•
•
•
•
•

Electronic document, typically in X.509 format

•

Signature usually comes from a Certification Authority

Used in PKI (public key infrastructure) systems
Includes a public key
Includes identity information for person or corporation
Includes hostname if intended to be used for TLS
Digitally signed
Signature attests that identity information and public key
belong together


11

Certificate Authorities
An aside on certificate authorities

•
•
•

ultimate source of the trust in the system
the authority signs the certificate
what happens if the authority is hacked?


12

Message-based security
Ties the security to the message

•
•
•
•
•
•
•

part or all of the message is encrypted
protects the data at rest
remains secure once it's received
can use intermediaries who can't read it
tied to a particular format
computationally expensive
difficult to implement and use


13

Some common web site
attacks


OWASP Top Ten
List of the top ten attacks, how they work, how to
prevent them. We'll look at three of the top ten:

•
•
•

SQL Injection
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)

More details: OWASP.org


15

SQL Injection Attacks

http://xkcd.com/327/


16

Example Code
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") +"'";

The attacker changes the query URL to http://example.com/app/accountView?id=' or '1'='1 which
leads to the complete query being
SELECT * FROM accounts WHERE custID='' or '1'='1'

'1'='1' is always true, so the query returns the entire account list.


17

Preventing SQL Injection Attacks

•
•

Stop writing dynamic queries and/or
Ensure malicious user-supplied input can't do anything

•
•
•
•
•

use prepared statements
use stored procedures
escape user-supplied input
principle of least privilege
principle of white list input validation

Check the OWASP SQL Injection Cheat Sheet for
more details


18

XSS Attacks
Cross-site scripting (aka CSS)

•

Malicious script tricks user’s browser into thinking it comes
from a trusted source

•

Can access cookies, security tokens, etc, as fully trusted

Example:

•
•

comment site allows full HTML

•

comment is on same site, so can access cookies etc defined by
that site, including, e.g., login info

attacking comment includes javascript that runs when victim
loads the page


19

Variations of XSS

•

Attacker crafts query URI and cons the victim into clicking on
it from email

•

Attacker (mis)uses some HTML element

•
•
•
•
•

script element, to load external script
add onload attribute to body element
put a script in the src attribute of an img element
put script in rel=“stylesheet” attribute of link element
put script in background attribute of table element


20

Preventing XSS Attacks
Multi-layer prevention is best

•

only allow characters that make sense in the context

•
•

e.g., don't allow input into a script
don't allow non-printable characters in name fields

•
•

ensure input data can't change the HTML DOM tree

•

consider escaping all “special” characters with the right
character or numeric entity (ASCII code under 256)

•

escape JavaScript, CSS, and URIs appropriately

escape all HTML/XML significant characters with entities, e.g.,
<

Check the OWASP XSS Prevention Cheat Sheet

21

WordPress
Basic security for WordPress sites:
http://codex.wordpress.org/Hardening_WordPress
(go to codex.wordpress.org and follow the links)
Data validation:
http://codex.wordpress.org/Data_Validation
Check plugins and themes to see if they use the
right functions
Other systems (Drupal, etc) have similar functions

22

CSRF Attacks
Cross-Site Request Forgery

•
•
•

victim is logged in somewhere
attacker convinces victim to run a script
script action is carried out, since victim is logged in

Prevention

•
•

add a random token to forms in a hidden field
for WordPress, use wp_nonce functions (e.g. at
http://crunchify.com/how-to-secure-your-wordpress-pluginprevent-csrf-vulnerability/)


23

While you're on the web
Good measures to not become a victim

•
•

load up your main browser with prevention plugins

•
•
•

use that browser for important sites

consider using NoScript or other XSS warning plugin/extension (http://noscript.net/faq#qa4_2)

log out of your bank site when you're finished
use a different browser for random surfing


24

Langara Computer Tech Meetup
February 21, 2014

Simple Principles for Website Security
Lauren Wood
lauren@textuality.com
slideshare.net/laurendw


25
25

Simple Principles for Website Security

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (17)

Semelhante a Simple Principles for Website Security

Semelhante a Simple Principles for Website Security (20)

Último

Último (20)

Simple Principles for Website Security