Web Application Security

Internet technology - IT00803

 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

Confidentiality

Non-Repudiation Authorization

Integrity Authentication
Availability
 5 ( ±2 ) Aspects of Security

Confidentiality Privacy

Non-Repudiation Authentication Authorization

Integrity 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
 Availability
 Authorized clients have timely and
reliable access to resources.
 Proper availability depends on application
 “Myth of the Nines”
 How reliable is 99.9% availability?
 Relevant technologies/techniques
 High availability protocols
 Redundancy
 System design without single point of failure
 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
 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 – mathematical transformations
 Symmetric vs. asymmetric
 Block vs. stream
 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

Source: Web Engineering, Kappel et. al.

 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

Source: Web Security, Privacy & Commerce. Garfinkel.

 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
Purpose Non-secure Secure

Web browsing HTTP HTTPS (SSL)

File Transfer FTP SFTP, SCP
Remote Telnet SSH
Access (UNIX)

 So, why aren’t the secure apps adopted?

 Security vs. convenience.
 Average user is unaware of them.
 Costs outweigh benefits.
 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 hashed or 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)
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 among the greatest at
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/.htpasswd
AuthName Admin Section
AuthType Basic

<Limit GET POST>

order deny,allow
deny from all
allow 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_errors = 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.
 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.
 PHP will parse all HTML files, reducing performance.
 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”
BYOP