Simple Principles for Website Security

1

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

Simple Principles for Website Security

Lauren Wood

[email protected]

slideshare.net/laurendw

Langara Computer Tech MeetupFebruary 21, 2014

1

2


Contents

Basics of HTTP and HTTPS

Some common security attacks

Protecting your site

Protecting yourself

2


HTTP and HTTPS

4


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

4

Client

GET /index.html HTTP/1.1+ headers

Server

200 OK + headers + index.html

5


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

5

Client

GET /index.html HTTP/1.1+ headers

Server401 unauthorized

username + password

resource + headers

6


HTTP Digest Authentication

• Encrypts the password using cryptographic hash aka 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)

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

6

7


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)

9


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

10


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

11


What is a Certificate?

• Electronic document, typically in X.509 format

• 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

• Signature usually comes from a Certification Authority

11

12


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

13


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

15


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

16


SQL Injection Attacks

16

http://xkcd.com/327/

17


Example Code

17

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

SELECT * FROM accounts WHERE custID='' or '1'='1'

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

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

18


Preventing SQL Injection Attacks

18

• 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

19


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

• attacking comment includes javascript that runs when victim loads the page

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

19

20


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

21


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

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

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

• escape JavaScript, CSS, and URIs appropriately

Check the OWASP XSS Prevention Cheat Sheet21

22


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

23


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-plugin-prevent-csrf-vulnerability/)

23

24


While you're on the web

Good measures to not become a victim

• load up your main browser with prevention plugins

• consider using NoScript or other XSS warning plug-in/extension (http://noscript.net/faq#qa4_2)

• use that browser for important sites

• log out of your bank site when you're finished

• use a different browser for random surfing

24

25


Simple Principles for Website Security

Lauren Wood

[email protected]

slideshare.net/laurendw

Langara Computer Tech MeetupFebruary 21, 2014

25

Simple Principles for Website Security

Technology

Transcript of Simple Principles for Website Security