web application security jonathan p. grady department of information science and telecommunications...
TRANSCRIPT
Web Application Security
Jonathan P. GradyDepartment of Information Science and Telecommunications
University of [email protected]
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”