Web Application Security

Jonathan P. GradyDepartment of Information Science and Telecommunications

University of PittsburghJpg14@pitt.edu

http://www.sis.pitt.edu/~jgrady

Overview

• What is Security?• 5 (+ or - 2) Aspects of Security• Fundamental Technologies• Secure Client/Server Interaction• Securing the Client• Securing the Server• Securing Web Applications

What is Security?

• The definition of security, as it applies, to the Web, is often too narrow.• An SSL-enabled Web application?• A properly patched and firewalled server?

• Service availability• Managing risk

• Traditional risk analysis• Best practices

• Compliance with legal obligations• Copyrights • Privacy laws

5 ( ±2 ) Aspects of Security

Confidentiality

Integrity Availability

5 ( ±2 ) Aspects of Security

Availability

Non-Repudiation Authorization

Confidentiality

Integrity Authentication

5 ( ±2 ) Aspects of Security

Non-Repudiation Authorization

Confidentiality

Integrity

Authentication

Privacy

Availability

Confidentiality

• Information exchanged between the client and service provider cannot be read by an unauthorized party.

• Encryption is the fundamental technology for ensuring confidentiality• Messages in transit• Messages in storage

• Confidentiality vs. Privacy• Confidentiality: Obligation of provider to

restrict access.• Privacy: individual right to control access.

Integrity

• The assurance that data & information cannot be altered.• Accidental corruption• Willful alteration

• Here, we discuss integrity in terms of data integrity• Data has not been altered during transmission• In CIA model, source integrity = authentication

• Primary technologies/techniques to ensure integrity:• Digital signatures• Hash algorithms• Checksums

Authentication

• Is the client (person or machine) really who they claim to be?

• The most secure authentication schemes use 3 factors:• Something you know – e.g., password• Something you have – e.g., key/token• Something you are – e.g., fingerprint

• Technologies• Login/password combination• Public Key Infrastructure• Biometrics

Availability

• Authorized clients have timely and reliable access to resources.

• Proper availability depends on application

• “Myth of the Nines”• How reliable is 99.9% downtime?

• Relevant technologies/techniques• High availability protocols• Redundancy• System design without single point of

failure

Authorization

• Allowing access only to those resources to which the client has been granted permission.

• Granting authorization may depend on:• Identity• Client characteristic (e.g., age, domain)

• Access control list (ACL) is still the primary technology.

• So, what’s the difference between authentication & authorization?

Non-Repudiation (Auditing)

• Preventing both the sender & receiver of information from denying their involvement in an exchange.• Sender receives proof of delivery.•Recipient receives proof of origin.

• Non-repudiation encompasses:• Approval & sending (origin)• Submission• Transport• Receipt & Knowledge (delivery)

Privacy

• The client’s expectation that their data will be released only to those parties that they authorize.

• Common view of privacy invasions• Cookies• Spyware

• Privacy expectations vary across societies and industries.• High: Europe, health care (HIPAA

Privacy Rule)• Low: North America in general

Fundamental Technologies

Introduction to Encryption

• A mathematical process for transforming a plain text message into cipher text.

• A cipher is an algorithm for encrypting or decrypting a message.• Classical ciphers – substitution &

transposition• Modern ciphers – symmetric & asymmetric

• A cipher is said to be strong if it cannot be broken by a brute-force attack (i.e., trying all possible keys)

Symmetric Key Algorithms

• The sender/receiver use the same key to encrypt/decrypt a message.

• Examples: AES, Blowfish, DES, Triple-DES• Not all algorithms are created alike.

• Secrecy of the key• Key length• Inversion of the encryption algorithm• Known parts of the plaintext.

• Biggest advantage: speed• Biggest disadvantages: key exchange,

storage

How DES Works

• 56-bit key length (64 – 8 parity bits)• Actual # of keys (human-entered) = 968

• No longer considered a “strong” algorithm.• Triple-DES produces effective length of 168 bits

Public Key Algorithms

• Sender and receiver employ different keys for encrypting/decrypting a message.• Each person/entity has a public-private key

pair• Private key must never be revealed!

• Examples• Diffie-Hellman – originally proposed in 1975.• RSA

• Most commonly used for encryption and digital signatures.

How Public Key Algorithms Work

Digital Signatures

• Rely on public key algorithms and hash functions to provide:• Integrity• Non-repudiation• Authentication

• A hash function (e.g., MD5, SHA-1) creates a small message digest, or fingerprint, of the much larger original message.

• By signing the digest with a private key, it becomes virtually impossible to alter a message without detection.

Digital Certificates & PKI

• In reality, public key encryption is viable provided we can trust the integrity of the public key itself.

• Public Key Infrastructures provide this integrity through delegated trust.• X.509 Digital Certificates – binds public keys

to identity of the private key holder• PGP and GPG

• A Certification Authority (CA) digitally signs issued certificates to vouch for the integrity of the certificate.

The Limits of Cryptography

• Encryption is but one of the tools necessary for Web security.

• Encryption alone doesn’t solve all security problems.• Unencrypted documents• Stolen keys• Denial-of-service attacks• Traffic analysis• Compromised encryption programs• Human errors

Secure Client/Server Interaction

Secure vs. Non-secure Apps

• So, why aren’t the secure apps adopted?• Security vs. convenience.• Average user is unaware of them.• Costs outweigh benefits.

Purpose Non-secure Secure

Web browsing HTTP HTTPS (SSL)

File Transfer FTP SFTP, SCP

Remote Access (UNIX)

Telnet SSH

Secure Sockets Layer (SSL)

• Originally released by Netscape (1996), allowing for:• Authentication of the server & client (dig.

sig.)• Confidentiality (encryption)• Integrity (message authentication codes)

• SSL’s features have made it popular• Separation of duties• Efficiency• Certificate-based authentication• Protocol agnostic (doesn’t require TCP/IP)• Protection against certain attacks

SSL Handshake, Step by Step

1. Client sends HTTPS request, including info about its cryptographic settings.

2. Server replies with its encryption settings and its certificate.

3. Client verifies validity of certificate.• Is issuing CA trusted?• Verify signature with CA’s public key.• Verify validity period.• Verify domain name.• Verify certificate is not on revocation list.

SSL Handshake, Step by Step -2

4. Client generates a “pre-master secret”, encrypts it using server’s public key, and sends to server.

5. Client & server generate a master secret based on the pre-master secret.

6. Using master secret, both client & server generate a symmetric key for the session.

7. Client informs server that future messages will be encrypted; sends encrypted messages acknowledging completion.

8. Server does the same.

Authentication Methods

• We’re all familiar with login/password.• Best practice: use SSL-secured connections.• Also wise to store encrypted passwords on

server.

• Digital Certificates• Can be used for email or web browsing.• Average user does not possess one.

• Single-sign on• Example systems: Kerberos, Microsoft Passport• Upon initial sign-on, clients receive a token.• Can be used across an organization or

enterprise.

Authorization & Access Controls

• Authorization policies specify what resources authenticated users may access.

• For files, access control lists (ACL) are the most popular mechanism.• Explicitly ALLOW or DENY access• OS or Web server level (e.g., .htaccess files in

Apache)• Individual, group, role, or everyone.• Domain, user characteristics, time of day, etc.

• For greater security, evaluation points (page, gateway) are separated from the decision point. (application)

Federation

• At the enterprise level – I.e., across multiple organizations – federated identity management allows for distributed authorization.

• 2 approaches:• Tightly-coupled – one central Decision Point.• Loosely-coupled – distributed Decision Points.

• Choice of approach depends upon what is more important to you: performance or autonomy• Tightly-coupled generally performs better.• Loosely-coupled preserves each unit’s autonomy.

Securing the Client

Overview

• What you can control, as a service provider:• SSL-enabled connections• Preserving Privacy• Sandboxes & Code signing

• What you can’t control• Desktop security

•Anti-virus applications•Firewalls•Intrusion detection

• Phishing and web spoofing

Preserving Privacy

• Platform for Privacy Preferences (P3P)• W3C standard for privacy policies (2002).• Supported by major browsers.

• An XML-based standard for publishing privacy policies.• Allows privacy agents (e.g., Privacy Bird) to

evaluate a website’s privacy policy for you.• Relies on “good-faith” of websites.

• Motivation• Help users gain more control over disclosure of

personal information.• Help organizations gain customer’s trust.

Sandboxing & Code Signing

• Sandbox: restricted environment for downloaded code (e.g., a Java applet).• E.g., Cannot access file system.• Restricts both “malicious” and “trusted”.

• If more functionality is required…• User adjust security policy (highly unlikely)• Service provider digitally signs code.

• Both Java and ActiveX rely on code signing.• Signed code is potentially trusted code.• Unsigned or untrusted code is rejected.

Securing the Desktop

• Threats enter the system at the most vulnerable points.• Email/websites• User curiosity

• Measures the average user is asked to take:• Patch operating system• Install, enable, and update virus protection• Install, enable, and update firewall• Beware of adware and spyware.

• Ongoing debate: automation vs. education

Phishing & Web Spoofing

• Because SSL makes intercepted messages virtually impossible to break, determined attackers go after the endpoints.• Steal data from server/client• Dupe clients into “volunteering data”

•Email and website look legitimate•Convincing URL’s

• Financial company websites are at greatest risk• Business based on trust.• Highest potential payoff for attacker.

Anti-Phishing Mechanism

Securing the Server

Physical Security

• The majority of attacks originate internally.• As with Web access, physical access should

be kept to the minimum required (least privilege).

• Though physical security needs vary dramatically, every organization should:• Have a physical security plan• Have a disaster security plan• Have a (data) backup plan, including

verification.• Contingency plans for loss of service, staff.• Protect hardware from heat, smoke, dust

Backing up Data

• You can’t predict the next emergency, so making regular backups is vital.

• Means of backup will depend on budget, value of data, amount of data• CD backups• Tape backups• RAID

• Back up anything unique to your system.• Performing the backup is not enough…

does the backup actually work???

Secure Operation

• The longer a computer is run, the less secure it becomes.

• As a system administrator, be sure to:• Patch your system• Keep informed of known vulnerabilities• Keep and rotate logs• Turn off unnecessary services • Of course, backups

• Utilize security tools• Tripwire – intrusion & change detection• KSA – snapshot & network scanning

More on Access Controls

• 3 Ways to restrict access• Hidden URL’s• Host-Based restrictions• Identity-Based restrictions

• An example .htaccess file in Apache:AuthUserFile /home/jgrady/htpasswd/.htpasswdAuthName EnterPasswordAuthType Basic

<Limit GET POST>order deny,allowdeny from allallow from 71.240.12 require user homework

</Limit>

Securing Web Applications

Securing Web Apps - Overview

• CGI, scripting languages, and server modules not only extend functionality, but also risk.

• Keys to writing secure code• Design carefully• Have someone else look at your design• Code and test iteratively• Validate all user-provided values – many bugs

arise because of unexpected input.• Check arguments to OS functions and return

codes.• Write to a dedicated log file.• Reuse (trusted) code.

Cross-Side Scripting (XSS)• An attack that exploits vulnerabilities in

dynamically Web pages -- lack of validation• Example: Simple check using alert( );

<script>alert(“Whoops”);</script>

• If the above works, then it’s possible for an attacker to grab cookies via a remote script.

• In PHP, simply passing the above through filter_input( ) would prevent the XSS.

• Additionally, validating the response is a good idea.

SQL Injections

• Passing code into an application that was not intended by the developer

• Takes advantage of poor input validation & other improper coding

• May also exploit over-privileged database accounts, gaining unauthorized access to data and OS resources

• Example: Type ‘ OR ‘ ‘ = ‘ into password field.• Scarier example:

'exec master..xp_cmdshell 'net user hacker1 nopassword /ADD'--

Securing PHP - Configuration

• The php.ini file gives you control over PHP’s behavior.

• Some best practices• Do not install the standalone binary in the cgi-

bin; install it outside the web server’s hierarchy.

• Install only those modules that are absolutely needed.

• Set display_error=off; log_errors=on;• Set register_globals=off;

• Look for any files named or titled “phpinfo*”, and remove them – there is no need to advertise this information.

• Consider using PHP in safe_mode.

Securing Your PHP Code

• Again, validate input, especially when…• Building SQL strings.• Running file commands.• Running system commands.

• Check user credentials on each page.• Protect session ID’s by using

session_regenerate_id( ) function.• PHP website suggests “hiding” your code by

making it look like some other file type (e.g., .html)• Security by obscurity is weak.• Another problem with .html suggestion – PHP will

parse all HTML files, reducing performance.

Securing Your CGI Programs

• Store all CGI scripts in your cgi-bin, and keep the cgi-bin clean.

• Only give admins and code owners write capabilities.

• Similar to PHP, avoid placing executables in publicly-accessible directories.

• Perl scripts that run shell commands• Again, avoid if possible.• Never trust user input.

• Use absolute paths when calling programs.

• Consider using secure wrappers (CGIWrap), so you don’t have to build secure code from scratch.

Threats to Availability• An attacker does not have to steal data to

cause economic loss.• Denial-of-service

• Preventing a web server from serving requests.

• Attacks can be on CPU, memory, or disk.• Can also the result of accidents or negligence.

• Buffer overflows• Caused by making erroneous assumptions

about the length of user input.• User input is larger than pre-allocated

memory•Best case: program crashes•Worst case: attacker gains control of system

Final Thoughts

• Like testing & documentation, security is the responsibility of all team members.•Multiple minds find more potential risks.•Blurring of the boundaries between

application and platform.• If nothing else, remember…

•Backup frequently!•Validate user input!•Keep your OS and security software up-

to-date•Use the concept of “least privilege”