Computer System Security

(040613601)

Computer Security System

Lecture 7 :
Web Security

By Assoc.Prof.Benchaphon Limthanmaphon, PhD.

 Objective
 Students learn
 how to exploit web vulnerabilities
 Web server attacks
 Web browser attacks
 How to develop a secure web application
 Students be able to understand the use of secure http (https)

2
 Contents
 HTTP Overview
 Cookies

 OWASP Top 10 Web vulnerabilities

 Cross-Site Request Forgery (XSRF)
 Web security Vulnerabilities
 Web Server Security
 Browser Attack

 Secure Transmission
 HTTPS
 SSL/TSL

3
 HTTP - Hyper Text Transfer Protocol
 is an application-level protocol.
 Standard for transferring documents on the World Wide Web
 The protocol is:
 Connectionless
 Media-independent
 Stateless
 Mostly all text
 HTTP is a request /response protocol – that is, a user agent (typically
a web browser on a PC) sends a request, and a remote server sends
a response to that request.
 A server response consists of:
 A status line, including the protocol version number, and a
success / error code, and
 A MIME-like message, containing server information, content
meta-information (headers), and content.
 The content will typically be written in HTML. 4
 HTTP (2)
Status code : 5 classes defined by the standard:
 1xx informational response – the request was received, continuing process
 100 Continue : status code in response before sending the body.
 2xx successful – the request was successfully received, understood, and
accepted
 200 OK : Standard response for successful HTTP requests.
 3xx redirection – further action needs to be taken in order to complete the
request
 301 Moved Permanently : This and all future requests should be directed
to the given URI.
 4xx client error – the request contains bad syntax or cannot be fulfilled
 403 Forbidden
 404 Not found
 5xx server error – the server failed to fulfil an apparently valid request
 500 Internal Server Error
5
 HTTP (3)
 HTTP is stateless
 The HTTP protocol does not require the server to maintain any protocol
state.
 The server does not keep any information to enable consecutive
requests from a single user agent to be linked.
 Hence HTTP does not support ‘sessions’
 e.g. as might be required to support e-commerce.
 HTTP Cookies are a simple means of enabling browser sessions with a
server.
The Cookie is then resubmitted with the
next request to the same server

server sends back state information in its

response header in the form of a Cookie
6
 Cookies
 A cookie header (in a response header) contains:
 attribute, the data payload;
 domain scope, enables sharing of cookies by web hosts with specified domain
name;
 path scope, limits the URI path to which the cookie should be sent back;
 expiration, the expiry date of the Cookie;
 SSL flag, if set the Cookie should only be sent back via an HTTPS (HTTP over
SSL) connection.
 Cookie Ownership
 Once a cookie is saved on your computer, only the Web site that created
the cookie can read it. A server can use Cookies to track individual user
 Variations
 Temporary cookies (Per-session cookies)
 Stored until you quit your browser
 Persistent cookies
 Remain until deleted or expire
 Third-party cookies
 Originates on or sent to another Web site 7
 Drawbacks of Cookies
 They do not always accurately identify users
 If more than one browser is used on a computer, each usually has a
separate storage area for cookies. Hence cookies do not identify a
person, but a combination of a user account, a computer, and a Web
browser.

 Cookie poisoning is the modification of a cookie by an attacker to gain

unauthorized information about the user for purposes such as identity
theft.
 The attacker may use the information to open new accounts or to
gain access to the user's existing accounts.
 Cookies can be stolen via packet sniffing in an attack called session
hijacking.
 A different way to steal cookies is cross-site scripting and making the
browser itself send cookies to servers that should not receive them.
8
 What is Web Application Security?
 Not Network Security
 Securing the “custom code” that drives a web application
 Securing libraries
 Securing backend systems
 Securing web and application servers

 Network Security Mostly Ignores the Contents of HTTP Traffic

 Firewalls, SSL, Intrusion Detection Systems, Operating System
Hardening, Database Hardening

 Definition
“Web security is a set of procedure, practices, and technologies for
protecting web servers, web users, and their surrounding organizations.
Security protects the user against unexpected behavior”
[Garfinkel and Spafford 1997]
9
 Code is Part of Security Perimeter
Security “perimeter” has huge
Application Layer

holes at the application layer

Legacy Systems

Human Resrcs
Web Services
Directories
Databases

Billing
Custom Developed
Application Code
APPLICATION
ATTACK

App Server
Network Layer

Web Server
Hardened OS

Firewall
Firewall

Network layer protection (firewall, SSL, IDS, hardening)

cannot be used to stop or detect application layer attacks 10
 Web Application Security Challenge
 Web applications are vulnerable to attack.
 They are an attractive target because they deliver data that is
valuable:
 Credit Cards
 Bank Accounts
 Personal Information
 Medical Information
 Email

 Frequent software updates and new website functionality increase the

potential for new web application vulnerabilities.
 Web application security assessments require a tremendous amount
of time, money, skill and diligence.

11
 Why web servers are compromised?
 Unnecessary default, back up, or sample files
 Installing the server with default settings
 Security conflicts with business ease-of-use case
 Improper files and directory permissions
 Misconfigurations in web server, operating systems, and networks
 Default accounts with their default or no passwords
 Lack of proper security policy, procedures, and maintenance
 Bugs in server software, OS, and web applications
 Security flaws in the server software, OS and applications.
 Misconfigured SSL certificates and encryption settings
 Improper authentication with external systems
 User of self-signed certificates and default certification
 Administrative or debugging functions that are enabled or accessible
 Unnecessary services enabled, including content management and
remote administration. 12
 Web Security - Threats
 Threats:
 Revealing private information on server
 Intercept of client information (client card fraud and abuse)
 Content hijacking (mimics of well known sites) and defacement
 Hostile content (recursive window pop ups)
 Cookies reveal where users have been, how many times ads
have been displayed (user profiling), allow impersonation

13
 Web Security - Vulnerabilities

https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
14
 Web Security - Vulnerabilities

https://owasp.org/www-project-top-ten/

15
 Web Security - Vulnerabilities
 OWASP (Open Web Application Security Project) top 10
vulnerabilities 2023
1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery

16
 OWASP – Top 10 Vulnerabilities
 Broken Access Control - include any issue that allows an attacker to bypass
access controls or that fails to implement the principle of least privilege.
 For example, a web application might allow a user to access another
user’s account by modifying the provided URL.
 Cryptographic Failures - include a failure to use encryption at all,
misconfigurations of cryptographic algorithms, and insecure key
management.
 This vulnerability can expose sensitive data such as passwords,
business records, credit card information, email addresses, patient
health records, or other personal user data.
 Injection - failure to properly sanitize user input before processing it.
 Using a safe API and positive server-side input validation can help in
preventing Injections.
 Insecure Design - this vulnerability describes failures in design that
undermine the security of the system

17
 OWASP – Top 10 Vulnerabilities (2)
 Security Misconfiguration - Unnecessary features enabled or installed,
outdated software, etc can also cause Security Misconfiguration.
 This threat can impact any layer of the application stack, cloud or
network, leaving important information to expose.
 Vulnerable and Outdated Components - If the components used in the
development of a website or application is outdated or is vulnerable itself,
it can compromise the whole application.
 For example, an application may import a third-party library that has its
own dependencies that could contain known exploitable vulnerabilities.
 Identification and Authentication Failures - Identification and authentication
failures occur when an application relies upon weak authentication
processes or fails to properly validate authentication information
 For example, an application that lacks multi-factor authentication
(MFA) might be vulnerable to a credential stuffing attack in which an
attacker automatically tries username and password combinations from
a list of weak, common, default, or compromised credentials
18
 OWASP – Top 10 Vulnerabilities (3)
 Software and Data Integrity Failures - It is to verify the installed packages
on your system and make sure that the data is from a reliable source and
has not been altered at any stage.
 This vulnerability class includes relying on third-party code from
untrusted sources or repositories.
 Security Logging and Monitoring Failures - vital to the maintenance of a
secure infrastructure. Viewing the logs regularly can be helpful in acting fast
in case any potentially dangerous activity is noticed.
 Server-Side Request Forgery - SSRF vulnerabilities can exist when a web
application does not properly validate a URL provided by a user when
fetching a remote resource located at that URL.
 An attacker exploiting the vulnerability can use the vulnerable web
application to send a request crafted by the attacker to the indicated
URL

19
 OWASP – Top 10 Vulnerabilities (4)
Typical exploitation of a server-side request forgery vulnerability
1. The attacker sends a forged request to a web server
that is vulnerable to SSRF and resides on the same
internal network as the target server.
2. The vulnerable web server sends the attacker-controlled
request to the victim’s server, bypassing the firewall.
3. The victim’s server responds to the web server
with the requested data. Web server makes
a request on
4. If the specific SSRF vulnerability permits it, behalf of the user
data is sent back to the attacker.

Direct request is
blocked by firewall
X
https://owasp.org/www-community/attacks/Server_Side_Request_Forgery 20
 Cross-Site Request Forgery (XSRF)
 forces a logged-on victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included
authentication information, to a vulnerable web application.
 This allows the attacker to force the victim’s browser to generate requests
the vulnerable application thinks are legitimate requests from the victim.
 cookie is sent to the site each time the browser accesses the site.
 cookie is used as an authentication token.
 Attacker: what if I force your browser to make my request to the secure
site with your cookie?
 Forces user to send unauthorized requests by interacting with a
malicious website.
 Can force someone to transfer money, change status on social
networking site, buy stock, or any other action on a vulnerable
website an attacker would like to exploit.
 XSRF impacts: Malicious site can’t read bank info, but can request bank
to do things benefit attackers – such as transfer money to them!
21
 Cross-Site Request Forgery (XSRF)
1. You log in https://www.bank.com. Do some bank stuff. But you have not
logged off yet.
2. You open another page www.attacker.com. This page has an evil form:

<form method="POST" name="evilform" target="hiddenframe"

action="https://www.bank.com/update_profile">
<input type="hidden" id="password" value="evilhax0r">
</form>
<iframe name="hiddenframe" style="display: none"> </iframe>
<script>document.evilform.submit();</script>

3. Your browser executes this form. The result is that the evilform is
submitted with a password-change request to bank.com’s “good” form:
www.bank.com/update_profile with a <input type="password"
id="password"> field.
4. You noticed nothing because nothing is displayed.
22
 Cross-Site Request Forgery (XSRF)
Normal Interaction

XSRF Attack

23
 Cross-Site Request Forgery (XSRF)
 Cookie Authentication is NOT Enough
• Users logs into bank.com, forgets to sign off
• Session cookie remains in browser state
• User then visits a malicious website containing
<form name=BillPayForm
action=http://bank.com/BillPay.php>
<input name=recipient value=badguy> …
<script> document.BillPayForm.submit(); </script>
• Browser sends cookie, payment request fulfilled

4
2 Server victim
User victim
Attack server

24
 Web Security Problems
 Securing the web server
 Securing the web client
 Securing information that travels between the web server and the user
Securing the application
Input validation Session mgmt Authentication
Authorization Config mgmt Error handling
Secure storage Auditing/logging
Web server App server DB server
firewall

firewall

apps apps database

host host host

Securing the network Securing the host

Router Patches/updates Accounts Ports
Firewall Services Files/directories Registry
Switch Protocols Shares Auditing/logging 25
 Web Server Attacks
 Denial-of-Service (DoS) Attacks: These attacks overwhelm a server with
traffic, making it unavailable to legitimate users.
 SQL Injection: Attackers inject malicious SQL code into input fields to
manipulate or steal data from the server's database.
 Cross-Site Scripting (XSS): Attackers inject malicious scripts into a
website, which are then executed by users' browsers, allowing them to steal
cookies, hijack sessions, or redirect users to malicious sites.
 File Inclusion: Attackers exploit vulnerabilities in file inclusion functions to
access or execute arbitrary files on the server.
 Directory Traversal: Attackers attempt to access files and directories
outside the web server's root directory.
 Remote File Inclusion (RFI): Attackers exploit vulnerabilities in file
inclusion functions to include and execute remote files.
 Session Hijacking: Attackers steal a user's valid session ID to gain
unauthorized access to their account
 Brute-Force Attacks: Attackers attempt to guess usernames and
26
passwords to gain access to the server.
 Web Server Attacks
 Certain implementations of HTTP can be used to create an HTTP bypass,
granting access to a server's activity logging functions.
 With these implementations, a Web page can be accessed and altered
without the system’s Web server recording the change.
 This method is often used to deface Web pages or Web defacement.

Message displayed
during defacement of
a UK National Health
Services website in
2018. Source: BBC.

27
 Web Server Security
 Discover
 Examine the environment
 Identify open ports eg. nmap
 Discover types/versions of apps running, Banner grabbing,
Extensions (.jhtml, .jsp, etc.) and directory structures
 Generate and examine errors
 Submit ridiculous input to provoke errors (fuzzing)
 Database errors, stack traces very helpful
 Find info left behind (source code, comments, hidden fields)
 Target
 Login mechanism - Input fields
 Session management - Infrastructure

28
 Web Server Attack Consequences

 Data breaches: Sensitive data, such as customer information or

financial records, can be stolen
 System downtime: Attacks can disrupt services and cause
significant financial losses
 Reputational damage: Security breaches can damage a company's
reputation and erode customer trust.

29
 Web Server Risk Mitigation
 Regular security audits and penetration testing
 Strong passwords and multi-factor authentication
 Regular software updates and patches
 Intrusion detection and prevention systems (IDPS)
 Web application firewalls (WAF)
 Proper server configuration and hardening

30
 Web Application Firewall (WAF)
 Inspection: WAFs meticulously examine every HTTP request and
response, looking for malicious patterns or suspicious activity.
 Filtering: Based on predefined rules and security policies, the WAF
filters out harmful traffic, such as:
 SQL Injection: Prevents attackers from injecting malicious SQL
commands into your database.
 Cross-Site Scripting (XSS): Blocks attempts to inject malicious
scripts into your website.
 Cross-Site Request Forgery (CSRF): Stops unauthorized
commands from being executed on behalf of authenticated users.
 Denial-of-Service (DoS) attacks: Protects your website from being
overwhelmed by excessive traffic.
 Blocking: When a WAF detects a malicious request, it blocks it
immediately, preventing it from reaching your web application.
 Logging and Reporting: WAFs keep detailed logs of all traffic, including
blocked attacks, which can be valuable for security analysis and
incident response. 31
 Web Client Security
 A web browser is a large software with many features
 Each feature is a potential security hole
 Web Client Security Problems
 Downloaded files
 may contain viruses and trojan horses
 Helper applications and plug-ins
 may run programs on your machine
 Javascript
 has security model
 ActiveX, etc.
 many security problems
 Cookies
 Allow sites to track usage
 Browser bugs
 many reported
 many still remain
http://www.cert.org/tech_tips/securing_browser/#how_to_secure 32
 Browser Attack
 Browser – software connects to a particular web address, fetches and
displays content from that address, and transmits data from a user to
that address.
 Browsers connect users to outside networks, but few users can
monitor the actual data transmitted
 Browser Attack Types
 Man-in-the-browser
 Keystroke logger
 Page-in-the-middle
 Program download substitution

33
 Browser Attack (2)
 Man-in-the-browser -Trojan horse that intercepts data passing through the
browser
 Ex Trojan horse called SilentBanker.
 This code linked to a victim’s browser as an add-on or browser helper
object; it listed itself as a plug-in to display video.
 When it detected the user going to a banking URL, it would intercept
keystrokes and even modify them so that money transfers would go to
attackers’ accounts.

34
 Browser Attack (3)
 Keystroke logger (or key logger)
 Hardware or software that records all keystrokes
 May be a small dongle plugged into a USB port or can masquerade as
a keyboard
 May also be installed as malware
 Not limited to browsers
 Page-in-the-middle
 User is directed to a different page than believed or intended
 Similar effect to a man-in-the-browser, where attacker can intercept
and modify user input
 Program download substitution
 Attacker creates a page with seemingly innocuous and desirable
programs for download
 Instead of, or in addition to, the intended functionality, the user installs
malware
 This is a very common technique for spyware 35
 Securing Data Transfer
 Secure Socket Layer (SSL)
 Encrypts data transferred between browser and server
 Identifies server
 (optionally identifies user - rarely used)
 Does not secure data once on the server (or client)
 secure HTTP: Protocol for securely transmitting individual messages
over the Web. A modified version of the standard HTTP protocol.
 SSL and S-HTTP use techniques such as encryption, digital
signatures, and:
 allow browsers and servers to authenticate each other
 allow controlled access to Web site
 ensure data exchanged between browser and server is secure and
reliable.

36
 Overview of SSL
 TCP provides a reliable end-to-end service
 SSL consists of two sublayers:
 SSL Record Protocol (where all the action takes place)
 SSL Management: (Handshake/Cipher Change/ Alert Protocols)

SSL Change
SSL Cipher Spec SSL Alert
HTTP, other
Handshake Protocol Protocol
apps
Protocol

SSL Record Protocol

TCP
37
 SSL Characteristics
 Operates at the TCP/IP transport layer
 Encrypts (decrypts) input from application (transport) layer
 Any program using TCP can be modified to use SSL connections
 SSL connection uses a dedicated TCP/IP socket
 (e.g. port 443 for https or port 465 for ssmtp)
 SSL is flexible in choice of which symmetric encryption, message
digest, and authentication algorithms can be used
 When SSL client makes contact with SSL server they try to pick
strongest encryption methods they have in common.
 SSL provides built in data compression
 compress first then encrypt

38
 SSL Characteristics (2)
 When SSL connection established browser-to-server and server-to-
browser communications are encrypted.
 This includes:
 URL of requested document
 Contents of the document
 Contents of browser forms
 Cookies sent from browser to server
 Cookies sent from server to browser
 Contents of HTTP header
 But NOT particular browser to particular server
 socket addresses not encrypted
 can use proxy server for privacy

39
 SSL Preliminaries
 An SSL Session is an association between a client and a server
 created by the Handshake Protocol
 There are a set of security parameters associated with each
session
 Session Identifier
 Peer Certificate: X.509v3 certificate of the peer
 Compression: Optional algorithm used to compress data
 Cipher Specs: Encryption Algorithm (3DES, AES, etc.) and
hash algorithm (MD5, SHA-1)
 Master Secret: 48-byte secret shared between client and
server
 An SSL Connection is a peer-to-peer relationship, and is transient.
 There may be many connections associated with one session.
 The same security parameters may apply to many connections.

40
 SSL Record Protocol
 The SSL Record Protocol uses the keys derived from the Handshake
Protocol to securely deliver data
 Two functions:
 Confidentiality and Message Integrity

Data

Fragmentation Chunk Chunk Chunk

Compression Shrunk

MAC Shrunk
Encrypt Encrypted

Header Encrypted
41
 SSL Record Protocol (2)
 SSL Record protocol allows protocols above SSL to be secured
 Example: HTTP delivers packets that are fragmented and
securely delivered
 SSL does not handle retransmissions… it does not have to! TCP
provides that functionality
 Messages are broken into blocks of at most 16384 bytes
 The compression is optional and, due to message size/type, it might
not even be desirable to use!
 Encryption may be stream or block mode. This is negotiated through
the Handshake protocol
 If block encryption, padding is necessary in order to fill out a block
length
 Padding is a sequence of padding bytes (random junk will do)
followed by 1 byte that describes length of the pad (up to 255).
42
 SSL Handshake Protocol
 Basically, the Handshake protocol is used before any application data
is transmitted.
 It is used to allow the server and client to authenticate each other
 To negotiate on an encryption and MAC algorithm
 Establish keys to be used
 The Handshake Protocol consists of messages consisting of three
fields:
 Type (1 byte): Indicates type of the message. There are 10 types.
 Length (3 bytes)
 Content: The payload exchanged in each message

43
 SSL Handshake Protocol 2
Client A Server G Round 1: Create the Connection between
the Client A and Server G, and figure out
what each entity can do!

1.A  G : {vers# , rA , SessID, CiphList, CompList}

2.G  A : {vers# , rG , SessID, CiphChoice, CompChoice}

• rA is a nonce made of 4 bytes of timestamp and

28 bytes of random #. Similarly for rG.
•SessID: 0 if new session, else is the session ID of
an existing session (and the Handshake will update
parameters)
•CiphList is a list of algorithms supported by the
client in an order of decreasing preference (Key
Exchange and Encryption Cipher)
•CiphChoice: The cipher suite chosen by the
Server.
44
 SSL Handshake Protocol 3
Client A Server G
 Round 2: Server Authentication and Key
Exchange
 Server begins by sending its X.509 cert (and
associated cert chain)
 Next, a public key is sent (e.g. modulus and
exponent, if RSA)
 Server may Request a Cert from the Client
 Server sends end round 2 message
3.G  A : {G _ X 509 Cert }
 
4.G  A : ( n G , e G ) || E K G hash ( rA || rG || ( n G , e G )) 
5.G  A : {CertType || ValidCertA uthorities }
6.G  A : {EndHello }

KG is the private key, and hence EKG is a signature

operation by the Server
ValidCertAuthorities identifies the authorities the
server will accept
45
 SSL Handshake Protocol4
Client A Server G Round 3: Client Authentication and Key
Exchange
 Client verifies that the Server’s Cert is valid, and
checks that parameters sent are valid
 If a cert was requested, then the Client sends one
 Server generates a PreMasterSecret sPM
7.A  G : {A _ X 509 Cert }

8.A  G : E  K G s PM  
9.A  G : hash ( MS || rG || hash ( Messages 1to8 || MS || rA ))
MS  MD 5s PM || SHA 1' A ' || s PM || rA || rG ||
MD 5s PM || SHA1' BB ' || s PM || rA || rG ||
MD 5s PM || SHA 1' CCC ' || s PM || rA || rG 

+KG is the public key, and hence E+KG is a encryption

using the public key gained from the certificate
Messages 1to 8 is the concatenation of first 8
messages
MS is master secret and Step 9 is for verification
46
 SSL Handshake Protocol 5
Client A Server G

 Round 4: Wrap-up
 Client tells Server to change cipher (via the
Change Cipher Protocol).
 Server responds with its own changed
cipher message
 Finished Message are hashes for
verification

10.A  G : {ChangeCipher}
11.A  G : hash MS || rG || hash (Messages1to9 || Client || MS || rA ) 
12.G  A : {CipherChanged}
13.G  A : hash MS || rG || hash (Messages1to9 || Server || MS || rA ) 

47
 SSL
Handshake
Summary

48