1 dsbw 2011/2012 q1

Security is fundamentally about protecting assets (data, hardware, reputation, etc.). Therefore you should

Identify potential threats

Detect and fix vulnerabilities

Know how to react to an attack

A threat is any potential occurrence, malicious or otherwise, that could harm an asset.

A vulnerability is a weakness that makes a threat possible, due to poor design, configuration mistakes, and/or inappropriate and insecure coding techniques.

An attack is an action that exploits a vulnerability or enacts a threat. Examples:

sending malicious input to an application

flooding a network in an attempt to deny service.

Unit 8: Security for Web Applications

2 dsbw 2011/2012 q1

Authentication (who are you?): the process of uniquely identifying the clients of your applications and services.

Authorization (what can you do?): the process that governs the resources and operations that the authenticated client is permitted to access.

Non-repudiation: guarantees that a user cannot deny performing an operation or initiating a transaction.

Confidentiality: the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized people.

Integrity: the guarantee that data is protected from accidental or deliberate (malicious) modification.

Availability: systems remain available for legitimate users.

Foundations of Security

3 dsbw 2011/2012 q1

poofing: Attempting to gain access to a system by using a false identity, eg. using stolen user credentials or a false IP address.

ampering: Unauthorized modification of data, for example as it flows over a network between two computers.

epudiation: The ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing, repudiation attacks are difficult to prove

nformation disclosure: Unwanted exposure of private data.

enial of service: The process of making a system or application unavailable.

levation of privilege: Occurs when a user with limited privileges assumes the identity of a privileged user to gain privileged access to an application.

Main Threat Categories:

4 dsbw 2011/2012 q1

Spoofing user identity Use strong authentication. Do not store secrets (eg., passwords) in plaintext. Do not pass credentials in plaintext over the wire. Protect authentication cookies with SSL.

Tampering with data Use data hashing and signing. Use digital signatures. Use tamper-resistant protocols Use protocols that provide message integrity.

Repudiation Create secure audit trails. Use digital signatures.

Information disclosure Use strong authorization. Use strong encryption. Use protocols that provide message confidentiality. Do not store secrets in plaintext.

Denial of service Use resource and bandwidth throttling techniques. Validate and filter input.

Elevation of privilege The principle of least privilege: use least privileged accounts to run processes and access resources.

STRIDE Countermeasures

5 dsbw 2011/2012 q1

Core Web Application Security Principles

Compartmentalize Create different security boundaries, zones, with their own

policies

Use least privilege Run processes using accounts with minimal privileges and

access rights

Apply defense in depth Use multiple gatekeepers to keep attackers at bay, do not

rely on a single layer of security

Do not trust user input Assume all input is malicious until proven otherwise

Check at the gate Authenticate and authorize callers early — at the first gate

Fail securely If an application fails, do not leave sensitive data

accessible. Return friendly errors to end users that do not

expose internal system details.

Secure the weakest

link

Identify it, strengthen it, fix it

Create secure defaults Make default users/actions/authorizations set up with least

privilege

Reduce your attack

surface

Disable or remove unused services, protocols, and

functionality.

6 dsbw 2011/2012 q1

Web Application Security: The Three-Tiered Approach

7 dsbw 2011/2012 q1

Integrating Security in the WebApp Process

8 dsbw 2011/2012 q1

The RACI Chart (Responsible, Accountable, Consulted, Kept Informed)

Tasks Architect System

Administrator Developer Tester

Security

Professional

Security Policies R A

Threat Modeling A I I R

Security Design Principles A I I C

Security Architecture A C R

Architecture and Design

Review R A

Code Development A R

Technology Specific Threats A R

Code Review R I A

Security Testing C I A C

Network Security C R A

Host Security C A I R

Application Security C I A R

Deployment Review C R I I A

9 dsbw 2011/2012 q1

Network Threats and Countermeasures

Threat Description Countermeasure

Information

Gathering

Port scanning and footprinting to

detect device types and vulnerable

operating systems and application

versions.

Configure routers to restrict their

responses to footprinting requests.

Disable unused protocols and

unnecessary ports.

Sniffing Monitoring traffic on the network for

data such as plaintext passwords or

configuration information

Use encrypted protocols (SSL,

IPSec)

Spoofing Hiding one’s true identity on the

network by using fake source

addresses

Filter packets

Session

Hijacking

Deceiving a server or a client into

accepting the upstream host as the

actual legitimate host

Use encrypted session negotiation

and communication channels.

Denial of

Service

Denying legitimate users access to a

server or services, e.g by sending

more requests to a server than it can

handle (SYN flood attack)

Increase the size of the TCP

connection queue, decrease the

connection establishment period,

and employ dynamic backlog

mechanisms.

10 dsbw 2011/2012 q1

Host Threats and Countermeasures

Threat Description Countermeasure

Viruses, Trojan horses,

and worms

Updated service packs and

software patches

Footprinting port scans, ping sweeps, and

NetBIOS enumeration to

glean valuable system-level

information

Disable unnecessary

protocols and ports

Password Cracking

Use strong passwords, limit

the number of retry attempts,

do not use default account

names

Denial of Service Deviate traffic to other hosts

Arbitrary Code Execution

Executing malicious code on

your server by using buffer

overflow attacks.

Lock down system

commands and utilities

Unauthorized Access

Unauthorized access to

restricted information or

operations

Lock down files and folders

with restricted permissions.

11 dsbw 2011/2012 q1

Application Threats

Category Threats

Input validation Buffer overflow; cross-site scripting; SQL injection; canonicalization

Authentication Network eavesdropping; brute force attacks; dictionary attacks; cookie

replay; credential theft

Authorization Elevation of privilege; disclosure of confidential data; data tampering;

luring attacks

Configuration

management

Unauthorized access to administration interfaces; unauthorized access

to configuration stores; retrieval of clear text configuration data; lack of

individual accountability; over-privileged process and service accounts

Sensitive data Access sensitive data in storage; network eavesdropping; data

tampering

Session management Session hijacking; session replay; man in the middle

Cryptography Poor key generation or key management; weak or custom encryption

Parameter manipulation Query string manipulation; form field manipulation; cookie manipulation;

HTTP header manipulation

Exception management Information disclosure; denial of service

Auditing and logging User denies performing an operation; attacker exploits an application

without trace; attacker covers his or her tracks

12 dsbw 2011/2012 q1

Application Countermeasures

Category Countermesures

Input Validation

Do not trust input; consider centralized input validation. Do not rely on

client-side validation. Be careful with canonicalization issues. Constrain.

reject, and sanitize input. Validate for type, length, format, and range.

Authentication

Partition site by anonymous, identified, and authenticated area. Use

strong passwords. Support password expiration periods and account

disablement. Do not store credentials (use one-way hashes with salt).

Encrypt communication channels to protect authentication tokens. Pass

Forms authentication cookies only over HTTPS connections.

Authorization

Use least privileged accounts. Consider authorization granularity. Enforce

separation of privileges. Restrict user access to system-level resources.

Configuration

Management

Use least privileged process and service accounts. Do not store

credentials in plaintext. Use strong authentication and authorization on

administration interfaces. Do not use the LSA. Secure the

communication channel for remote administration. Avoid storing sensitive

data in the Web space.

Sensitive Data

Avoid storing secrets. Encrypt sensitive data over the wire. Secure the

communication channel. Provide strong access controls on sensitive data

stores. Do not store sensitive data in persistent cookies. Do not pass

sensitive data using the HTTP-GET protocol.

13 dsbw 2011/2012 q1

Application Countermeasures (cont.)

Category Countermeasures

Session Management

Limit the session lifetime. Secure the channel. Encrypt the contents of

authentication cookies. Protect session state from unauthorized access.

Cryptography

Do not develop your own. Use tried and tested platform features. Keep

unencrypted data close to the algorithm. Use the right algorithm and key

size. Avoid key management (use DPAPI). Cycle your keys periodically.

Store keys in a restricted location.

Parameter Manipulation

Encrypt sensitive cookie state. Do not trust fields that the client can

manipulate (query strings, form fields, cookies, or HTTP headers).

Validate all values sent from the client.

Exception Management

Use structured exception handling. Do not reveal sensitive application

implementation details. Do not log private data such as passwords.

Consider a centralized exception management framework.

Auditing and Logging

Identify malicious behavior. Know what good traffic looks like. Audit and

log activity through all of the application tiers. Secure access to log files.

Back up and regularly analyze log files.

14 dsbw 2011/2012 q1

Web Application Security: Summary

15 dsbw 2011/2012 q1

The coding of messages so as to render them unintelligible to

other than authorized recipients. Many techniques are known

for the conversion of the original message, known as

plaintext, into its encrypted form, known as ciphertext, cipher,

or code

Dictionary of Computing. Oxford University Press, 2004

Cryptography

“

”

16 dsbw 2011/2012 q1

Authentication: Digital signatures can be used to identify a participant in a web transaction or the author of an email message

Authorization: Cryptographic techniques can be used to distribute a list of authorized users that is all but impossible to falsify.

Confidentiality: Encryption is used to scramble information sent over networks and stored on servers so that eavesdroppers cannot access the data's content

Integrity: Methods that are used to verify that a message has not been modified while in transit. Often, this is done with digitally signed message digest codes.

Nonrepudiation: Cryptographic receipts are created so that an author of a message cannot realistically deny sending a message

Roles for Cryptography

17 dsbw 2011/2012 q1

Symmetric Key Cryptography

18 dsbw 2011/2012 q1

Public Key (aka Asymmetric) Cryptography

19 dsbw 2011/2012 q1

Authentication with Public Key Cryptography

20 dsbw 2011/2012 q1

Digital envelope

21 dsbw 2011/2012 q1

Virtual Private Networks (VPN)

Internet Protocol Security (IPSEC)

Point-to-Point Tunneling Protocol (PPTP)

Layer Two Forwarding (L2F)

Layer Two Tunneling Protocol (L2TP)

E-mail Encryption

Secure Multipurpose Internet Mail Extensions (S/MIME)

Pretty Good Privacy

WWW i e-commerce

SSL/TSL

Secure Electronic Transaction (SET)

Cryptography-based Internet Protocols

22 dsbw 2011/2012 q1

SSL – Secure Socket Layer

TLS – Transport Layer Security

Both provide a secure transport connection between clients and servers:

Authentication of the server, using digital signatures

Authentication of the client, using digital signatures

Data confidentiality through the use of encryption

Data integrity through the use of message authentication codes

History:

SSL was developed by Netscape

SSL version 3.0 has been widely used on the Internet

SSL evolved into TLS (RFC 2246)

TLS can be viewed as SSL v3.1

SSL/TSL

23 dsbw 2011/2012 q1

SSL architecture

SSL Record Protocol

SSL

Handshake

Protocol

SSL Change

Cipher Spec

Protocol

SSL

Alert

Protocol

applications

(e.g., HTTP)

TCP

IP

24 dsbw 2011/2012 q1

SSL Record Protocol

fragmentation

compression

message authentication and integrity protection

encryption

SSL Handshake Protocol

negotiation of security algorithms and parameters

key exchange

server authentication and optionally client authentication

SSL Alert Protocol

error messages (fatal alerts and warnings)

SSL Change Cipher Spec Protocol

a single message that indicates the end of the SSL handshake

SSL Components

25 dsbw 2011/2012 q1

An SSL session is an association between a client and a server

SSL sessions are stateful: the session state includes security algorithms and parameters

A SSL session may include multiple secure connections between the same client and server

SSL sessions are used to avoid expensive negotiation of new security parameters for each connection

SSL sessions and connections

26 dsbw 2011/2012 q1

SSL Record Protocol: Processing

application data

MAC padding type

fragmentation

compression

msg authentication and

encryption (with padding if necessary)

version length

type version length

type version length

SSLPlaintext

SSLCompressed

SSLCiphertext

27 dsbw 2011/2012 q1

SSL Handshake Protocol

client server

client_hello

server_hello

certificate

server_key_exchange

certificate_request

server_hello_done

certificate

client_key_exchange

certificate_verify

change_cipher_spec

finished

change_cipher_spec

finished

Phase 1: Negotiation of the session ID, key exchange

algorithm, MAC algorithm, encryption algorithm, and

exchange of initial random numbers

Phase 2: Server may send its certificate and key

exchange message, and it may request the client

to send a certificate. Server signals end of hello

phase.

Phase 3: Client sends certificate if requested and may

send an explicit certificate verification message.

Client always sends its key exchange message.

Phase 4: Change cipher spec and finish handshake

28 dsbw 2011/2012 q1

http://www.w3.org/Security/Faq/www-security-faq.html

Web Security, Privacy & Commerce, 2nd Edition, by Simson Garfinkle with Gene Spafford, O'Reilly, 2001.

Improving Web Application Security: Threats and Countermeasures, by Microsoft Corporation, Microsoft Press, 2003

References