Web and Browser

Security
Computer Security | Lecture Six
 Lecture Outline
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Introduction
▪ A lot can go wrong on the Web Executable Content (if any),
through Browser-server ▪ The browser can be redirected to
Interactions other sites.
▪ As web resources are transferred ▪ Much of this occurs without User
and displayed to users. Involvement or Understanding
▪ When a Browser visits a website, ▪ Pages may recursively pull in
the browser is sent a page (HTML content from multiple sites
document). ▪ Including scripts (active content)
▪ The Browser renders the document ▪ e.g., in support of the Internet’s
by first assembling the specified underlying advertising model
pieces and executing embedded
 Introduction

▪ Two Security Foundations ▪ This lecture will look at the

discussed in this lecture are following attacks
▪ Secure HTTP (HTTPS) ▪ Cross-Site Request Forgery
▪ How HTTP traffic is sent over (CSRF)
TLS ▪ Cross-site Scripting (XSS)
▪ The role of HTTP proxies and ▪ SQL Injection
HTTP cookies
▪ Phishing
▪ Same-Origin Policy (SOP)

5
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Web Review:
Domains, URLs, HTML, Scripts

▪ The Domain Name System (DNS)

▪ Domain Name: consists of a series of one or more dot separated
parts, except for the DNS root, which denoted by a dot “.” alone
▪ Top-level domains (TLDs) e.g. .com and .org,
▪ Country-code TLDs (ccTLDs), e.g., .ng and .uk.
▪ Generic Top-Level Domain (gTLD) e.g. .edu .gov

7
 Web Review:
Domains, URLs, HTML, Scripts
▪ Uniform Resource Locators ▪ i.e., a computing device that has
a corresponding IP address;
(URLs)
▪ User-friendly domain names can
▪ Specifies the Source Locations
be used (vs. IP addresses)
of files and web pages.
based on DNS utilities that
▪ As shown in the Address Bar translate (resolve) an FQDN to
▪ A URL is the most-used type of an IP address
uniform resource identifier (URI) ▪ FQDN: Fully Qualified Domain
▪ Hostname refers to an Name is the complete domain
addressable machine name for a specific computer,
or host, on the internet

8
9
 Web Review:
Domains, URLs, HTML, Scripts
▪ Hypertext Markup Language (HTML) is a system for annotating
content in text-based documents, e.g., web pages.
▪ Uses Markup Tags to format for display on Web Browsers
▪ Tags come in pairs to identify structures such as Paragraphs and
Headings.
▪ Text appearing between Tags is the actual content to be formatted.
▪ A hyperlink specifies a URL identifying a web page from a
separate location
▪ An anchor tag associates such a URL with a string to be displayed
<a href="url">textstring-for-display</a>
10
 Web Review:
Domains, URLs, HTML, Scripts

▪ HTML documents may also contain tags identifying

segments of text containing code from a Scripting
language to be executed by the browser
▪ The Scripts manipulate the displayed page and underlying
Document Object
▪ Scripts can also be invoked conditionally on Browser-detected Events,
as event handlers.
▪ The most popular scripting language used for these is
JavaScript
11
 Web Review:
Domains, URLs, HTML, Scripts
▪ JavaScript execution proceeds document before the loading
as follows, as a new document process completes
is loaded: ▪ The dynamically constructed
text is then injected inline within
1. Script elements execute in order the HTML document.
of appearance, as encountered ▪ When Script completes
by the HTML parser execution, HTML parsing
▪ The Script is also interpreted as continues, starting at this new
it parses. text.
2. JavaScript may call ▪ The method may itself write
new scripts into the
[Link]() to document.
dynamically inject text into the
12
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Hypertext Transfer Protocol (HTTP)
▪ HTTP is the primary protocol ▪ The Request-methods are
for data transfer between Web ▪ GET (no Body allowed)
Browsers and Servers. ▪ POST (Body is allowed)
▪ The Browser opens a TCP ▪ CONNECT
connection to a server, and then ▪ The REQUEST-URI is the
makes an HTTP Request requested Object.
consisting of: ▪ The HTTP Response is
▪ Request-line structured similarly
▪ Header ▪ The request-line is replaced by
▪ Optional Body a status-line summarizing how
the server fared

14
15
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 HTTP and Web Forms
▪ HTML documents may include ▪ Entered data is concatenated into a
Web Forms String as a sequence of
“fieldname=value” pairs
▪ Forms solicits user input into
specified fields ▪ If the POST method is used
▪ String is Put into an HTTP request
▪ “Submit” button signals that data
body
entry is complete
▪ If the GET method is used
▪ Specifies a URL to which an HTTP
▪ Recall GET has no body
request will be sent as the action
resulting from the button press ▪ String is appended as query data at
the end of the request-URI in the
▪ On clicking the Button request-line

17
 HTTP | Referer Header
▪ The Referer Header is designed to parameters),
hold the URL of the page from ▪ some Browsers remove the Referer
which the request was made data if it would reveal, e.g., a local
filename.
▪ Informs the host of the newly
requested resource the originating ▪ It’s safer to submit Forms using
URL, and potentially ending up in the POST
logs of both servers. ▪ GET-method append user-entered
▪ Some Browsers allow users to data into query field arguments
disable use of this header ▪ Since, Referer Header propagate
▪ For privacy reasons (e.g., browsing sensitive data
history, leaking URL query

18
 HTTP Proxies
▪ An HTTP proxy or proxy server is modifications or translations
an intermediary service between a needed for interoperability,
Client and an Endpoint Server ▪ keeps audit logs,
▪ Negotiates access to endpoint ▪ Inspecting content and performing
server resources and relays other firewall functions.
responses ▪ Provides Caching efficiency
▪ Acts as a server to the client, and as ▪ Identical content requested multiple
a client to the endpoint server. times, including by different clients,
can be retrieved from a locally
▪ HTTP Proxies stored copy
▪ Handle any header/content

19
20
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Browser (URL) Redirection

▪ When a browser “visits a web page”, an HTML document is

retrieved over HTTP, and locally displayed on the client device.
▪ The Browser follows instructions from both the HTML document
loaded, and the HTTP packaging that delivered it.
▪ HTML and HTTP mechanisms also allow the browser to be redirected
(forwarded) to other sites
▪ Legitimate reasons include:
▪ Web page having moved
▪ Available mobile-friendly version of the site
▪ Different domain for credit card payments

22
 Browser (URL) Redirection

▪ Browser redirect can also be used for malicious purposes.

▪ The following are possible Automated Redirection
instances
▪ JavaScript redirect (within HTML)
▪ Refresh Meta Tag (within HTML)
▪ Refresh Header (in HTTP response)
▪ HTTP Redirection (in HTTP response, status code 3xx

23
 Browser (URL) Redirection
▪ JavaScript Redirect (within ▪ Refresh meta tag (within HTML)
HTML) ▪ The current page is replaced on
▪ The location property of the window executing:
object (DOM) can be set by <meta http-equiv="refresh"
JavaScript content="N; URL=new-url">
[Link]="url" or ▪ This redirects to new-url after N
[Link]="url" seconds (immediately if N = 0).
▪ Assigning a new value in this way ▪ If URL= is omitted, the current
allows a different document to be document is refreshed.
displayed. ▪ This tag works even if JavaScript is
disabled

24
 Browser (URL) Redirection
▪ Refresh header (in HTTP ▪ HTTP redirection (in HTTP
response) response, status code 3xx)
▪ On encountering the HTTP ▪ Here, an HTTP header: specifies
header: the redirect target.
Refresh: N; url=new-url ▪ A web server may arrange to
▪ The browser will, after N create such headers by various
seconds, load the document means
from new-url into the current ▪ By a server file with line entries
window that specify:
▪ Immediately if N = 0 ▪ (requested-URI, redirect-status-
code-3xx, URI-to-redirect-to).

25
 Browser (URL) Redirection

▪ Browser Redirection can thus be caused by many agents:

▪ Web Authors controlling HTML content
▪ Server-side Scripts that build HTML content
▪ Some may be authorized to dictate,
▪ e.g. HTTP response Location headers
▪ Server Processes creating HTTP response headers
▪ Malicious Party that can Author, Inject or Manipulate these items
▪ Drive-by-Downloads, Phishing, Middle-person-attack

26
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Transport Layer Security (TLS) and HTTPS
HTTP over TLS
▪ HTTPS (Secure), is the main A. Key Exchange (authenticated
key establishment; finalizes
protocol that secures web all crypto parameters)
traffic B. Server Parameters (all other
options and parameters are
▪ Client sets up a TLS channel to finalized by the server)
a server over an TCP connection C. Integrity and Authentication
to transmits HTTP data. (of server to client, and
▪ A TLS client-server Channel optionally client to server)
involves 2 Stages 2. Record Layer: This protects
application data, using
1. Handshake Layer (parameter
parameters as negotiated.
set-up). The handshake
involves 3 functional parts: ▪ TLS succeeds the SSL
28
 Transport Layer Security (TLS) and HTTPS
HTTP over TLS

▪ Once Handshake part A) completes, parts B) and C) can

then be Encrypted.
▪ The Design Intent: Attackers cannot influence any resulting
parameters or keying material;
▪ At worst, an attack results in the endpoints which would declare a
Handshake Failure.

29
30
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 HTTP Cookies and Session IDs
▪ HTTP itself is a Stateless protocol ▪ Server passes size-limited data
▪ State is not retained across strings to the Browser
successive HTTP requests ▪ Browser returns the Strings on later
requests to the same Server
▪ Not consistent with how websites
▪ These are Short-lived Session
functions - hyperlinked Cookies stored in browser memory;
▪ Most Successive page loads are ▪ Server-set attributes can extend
typically related Cookie lifetime into Persistent
▪ State retention enables Cookies
Convenience and Functionality ▪ Subdomains, as logically distinct
▪ HTTP cookies provides the from higher-level domains, have
experience of Browsing Sessions their own cookies.

32
 HTTP Cookies and Session IDs

▪ To facilitate browser sessions, servers store a Session ID

(randomly chosen number) in an HTTP cookie.
▪ Session ID indexes Server-side State related to ongoing interaction.
▪ Sites that require User Authentication
▪ The user typically logs in to a Landing Page, but is not asked to re-
authenticate for each later same-site page visited
▪ Instead, the Authenticated Session is recorded by either server-side state or
in the session ID cookie itself – called an Authentication Cookie

33
 HTTP Cookies and Session IDs
▪ Server may specify a session Browser has not Disabled
persistent cookies
expiration time shorter than
the cookie lifetime. ▪ Such Cookies are an attractive
targets suppose there are
▪ After expiration, re- authenticated session benefits
authentication will be needed
▪ Such as link to an account with
▪ Authentication Cookie may a permanently stored credit
extend the authenticated card number or other sensitive
session beyond the lifetime of resources.
the browsing window, to days or ▪ Cookie Theft thus allows HTTP
weeks later. session hijacking
▪ If the cookie is Persistent and

34
 Cookie Theft | Client-side Security Risks
▪ Authentication cookies may be ▪ The Secure cookie attribute
mandates HTTPS or similar
stolen by means including protection.
▪ Malicious JavaScript in HTML ▪ Non-script client-side malware
documents, e.g., sending cookies to
▪ Such malware defeats most client-
a malicious site side defenses
▪ Setting the HttpOnly cookie
▪ Physical or other unauthorized
attribute stops script access to
cookies.
access
▪ to the Filesystem or Memory of the
▪ Untrustworthy HTTP Proxies,
client device on which Cookies are
Middle-persons and Middleboxes stored
▪ If cookies are sent over HTTP

35
 Cookie DOM API

▪ The DOM API [Link] returns all cookies for

the current document.
▪ A Browser evicts an existing cookie if a new one is received with the
same cookie-name, Domain attribute, and Path attribute.
▪ A Browser can disable Persistent Cookies;
▪ The Boolean Property [Link] is used by several
browsers to track this state.

36
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Same-Origin Policy (DOM SOP)

▪ Same-origin Policy (SOP) is an Isolation and Access

Control philosophy to isolate documents.
▪ The general idea is that a Page (document) from One Source
(Origin) should not be able to Interfere with (access or manipulate)
one from another source.
▪ This obeys the Principle P5 of Isolated-compartments

38
 Motivation for SOP
▪ If a browser loads pages from application security model
distinct domains host1 and host2, ▪ The Browser permits scripts in a
without rules to prevent mixing of Page to access data in a second
their content page, only if both web pages have
the same Origin
▪ The JS from host1 in one Page
▪ Origin: a combination of URI
might access or alter data
scheme, host name, and Port
associated with host2 in another. Number (aka Origin Triplet)
▪ Problematic: if host1 is malicious
▪ SOP protects against reusing
and host2 is a banking site.
Authenticated Sessions across
▪ SOP is an Important web origins

39
 Same-Origin Policy | Rules
▪ Some Rules are thus ▪ A base HTML document is
needed. assigned an origin, derived
from the URI that retrieved it;
▪ Overly strict host isolation
policies might rule out ▪ Scripts and images are
desirable interaction between assigned the origins of the
cooperating subdomains HTML documents that cause
them to be loaded
▪ E.g., catalog and purchasing
divisions of an online store ▪ Scripts may access content
whose assigned Origin
▪ The Basic SOP Rules matches their own.
40
41
Can you Explain?

42
43
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Cross-Site Request Forgery Attacks

▪ Cross-Site Request Forgery (CSRF) is a type of malicious

exploit of a website where unauthorized commands are
submitted from a user that the web application trusts
▪ Aka One-click Attack or Session Riding
▪ The use of HTTP cookies as Authentication Cookies has led to
numerous security vulnerabilities.

45
46
47
48
 Cross-Site Request Forgery Attacks

▪ Beyond funds transfer as end-goal, a different CSRF attack goal

might be to change the email-address-on-record for an account
▪ Often being used to hijack Account Recovery
▪ Further remarks about CSRF attacks follow
▪ Any response will go to Alice’s user agent, not Charlie; thus CSRF
attacks aim to achieve their goal in a single HTTP request.
▪ CSRF attacks rely on victims being logged in to the target site; financial
sites thus tend to avoid using persistent cookies, to reduce the
exposure window

49
 Mitigating CSRF Attacks

▪ Secret Validation Tokens are one defense against CSRF.

▪ As a session begins, the server sends the browser a unique (per-
session) secret.
▪ On later HTTP requests, the browser includes a function of the
secret as a token, for the server to validate.
▪ The idea is that a CSRF attacker, without access to the secret,
cannot generate the token

50
 Mitigating CSRF Attacks | Best Practices

▪ From a user’s perspective, Prevention is a matter of:

▪ Safeguarding login credentials
▪ Denying unauthorized actors access to applications.
▪ Some Best practices include:
▪ Logout of Web applications when not in use
▪ Secure Usernames and Passwords
▪ Don’t allow Browsers to Remember Passwords
▪ Avoid simultaneously browsing while logged into an application

51
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Cross-site Scripting (XSS) Attacks

▪ XSS involves Injection of malicious HTML Tags or Scripts

into web pages
▪ Such that rendering HTML on user agents (browsers) results in
actions intended by neither legitimate sites nor users.
▪ Allows attackers to circumvent the Same Origin Policy
▪ A victim’s Cookies can be sent to an attacker’s site
▪ XSS on websites accounted for roughly 84% of all security
vulnerabilities documented by Symantec up until 2007

53
 Types of XSS

▪ Reflected XSS:
▪ Malicious script comes from the current HTTP request
▪ Stored XSS
▪ Persistent or Second-order XSS
▪ Malicious script comes from the website's database
▪ DOM-based XSS
▪ Vulnerability exists in client-side code rather than server-side code

54
 Reflected XSS
▪ It arises when an application receives data in an HTTP request
and includes that data within the immediate response in an
unsafe way
▪ Simplest variety of XSS
▪ Example: Suppose a user is redirected to, or lands on, an
attacker-controlled site [Link], and legitimate site
[Link] responds to common file-not-found errors with
an error page generated by a parameterized script
File-not-found: filepath-requested

55
56
 Example | Stored XSS

▪ Suppose a web forum allows users to post comments

embedded into pages for later visitors to see
▪ A malicious user may provide the following input

▪ General Form
harmless-text <script> arbitrary-malicious-JavaScript </script>

57
58
 XSS | Potential Impacts

▪ Potential outcomes include:

▪ Browser redirection, including to attacker-controlled sites;
▪ Access to authentication cookies and other session tokens;
▪ Access to browser-stored data for the current site;
▪ Rewriting the document displayed to the client
▪ E.g., with [Link]() or other methods that allow
programmatic manipulation of individual DOM objects.

59
 Mitigating XSS Attacks
▪ Input sanitization is the process of removing potentially
malicious elements from data input, including
▪ Input filtering by use of allowlists, denylists
▪ Removing tags and event attributes such as <script>, <embed>,
<object>, onmouseover; and output escaping.
▪ Server-side Filtering may stop simple XSS attacks but leads to
filter evasion tactics.
▪ To defuse malicious injection of HTML markup tags, filters replace <
and > by &lt and &gt
▪ Therefore, the Browser parsers process &ltscript&gt as regular text

60
61
 Mitigating XSS | Evading Filtering
▪ To evade filters seeking the string “<script>”, an injected code
may use alternate encodings for the functionally equivalent string
“&#x3C;&#x73;cript&#x3E;”
▪ First 12 characters encode ASCII “<s”
▪ To address such evasive encodings
▪ A Canonicalization step can be used to map input (including URIs) to a
common character encoding.
▪ Another standard evasion injects code to dynamically construct
that string, e.g., by JavaScript string concatenation.
62
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 SQL Injection Attacks

▪ Structured Query Language (SQL) is used to Query

databases
▪ Server-side Scripts can construct and send SQL queries for
execution on back-end databases
▪ SQL queries are dynamically constructed using data from Cookies,
Variables, and Other Sources populated by Input from Users or
other programs

64
 SQL Injection Attacks

▪ SQL Injection refers to ▪ Unauthorized account access

and Denial Of Service.
inserting data with intent that
attacker-chosen commands ▪ The root cause is as in other
are executed by an SQL server injection attacks:
on a Database. ▪ Data input from untrusted
interfaces goes unsanitized
▪ SQL Injection ranks in the top 3
in lists of web security issues ▪ This results in execution of
unauthorized commands
▪ Objectives ranges:
▪ Extraction or Modification of ▪ .
sensitive data

65
 SQL Injection Attacks
▪ A common case involves scripts using String
Concatenation to embed user-input data into dynamically
constructed SQL query strings.
▪ The resulting strings, sent to an SQL server are processed based on
specific syntax and structure

66
 Example | SQL Injection
▪ Suppose a user logging into a web site is presented a
browser form and enters a username and password.
▪ An HTTP request conveys the values to a webpage, where a server-
side script assigns them to string variables (un, pw).
▪ The values are built into an SQL query string, to be sent to a back-
end SQL database for verification.
▪ The script constructs a string variable for the SQL query as follows:
query = "SELECT * FROM pswdtab WHERE username='" + un +
"’ AND password='" + pw + "’"
67
 Example | SQL Injection

▪ Let’s see what query string results if for un, the user types in
“root’ --” | Query becomes:
SELECT * FROM pswdtab WHERE username='root' -- AND
password='" + pw + "'"
▪ Since “- -” denotes a line-ending comment, what follows it is ignored.
▪ This eliminates the condition requiring a password match, and the
record for the root account is returned
▪ The app server assumes a successful check, and grants user
access as root

68
 Example | SQL Injection

▪ A variation appends an always-true OR condition, to result in

a conditional check always returning TRUE.
▪ E.g as in the following result upon a user entering (for un)

'OR 1=1 -–
▪ The Query becomes
SELECT * FROM pswdtab WHERE username='' OR 1=1 –-
▪ Depending on the database, this may return every record in the table!

69
 Mitigating SQL Injection Attacks
▪ Escaping unexpected keywords
▪ Adjust received input to remove a ▪ e.g drop, shutdown, insert
subset of clearly identified problems ▪ Drawback: Always incomplete, and
▪ Drawback: Prone to errors; requiring update as each new attack
becomes known
▪ Output escaping of special
characters is a good start ▪ Positive Validations
▪ Ad hoc solutions are subject to ▪ Allow only known-good input, i.e.,
endless move-countermove games use Allowlists
with attackers
▪ Drawback: Requires precise (and
▪ Input filtering by Denylists correct) specification of allowed
▪ Reject known-bad input or inputs, or predefined query formats

70
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Phishing Attack
▪ Phishing is the act of impersonating a legitimate website in order
to obtain information without authorization
▪ Info: Passwords, Credit card numbers, etc.
▪ Phishing attack is carried out by
▪ A link (e.g., in an email, messaging service, web search result, or on
another web site)
▪ Browser redirection
▪ The site may connect to and mirror info from the legitimate site to
convince users

72
 Phishing Attack

▪ Spear Phishing: When phishing targets specific individuals

as against generic attack
▪ Attacks that purport to come from a known contact (a compromised
email address book) may increase attack success
▪ Typosquatting: tactic involves registering web domains
whose URLs are common misspellings of a legitimate site;
▪ Mistyping a legitimate URL into a browser URL bar then delivers
users to a fake site
73
 Example | Phishing Enablers

▪ Many factors enable phishing.

▪ User mental models are governed by information received through
the user interface (UI), and visual deception is easy.
▪ Information displayed on a screen can be entirely different from
underlying technical details:
<a href="[Link]
▪ Displays [Link] while [Link] is the actual
hyperlink.

74
 Mitigating Phishing Attacks
▪ Remove the sources of links to sites.
phishing sites ▪ There exist a shared lists of
▪ By Spam Filtering of phishing malicious websites
emails by service providers; ▪ These techniques have
▪ Large email providers have substantially reduced Phishing
become proficient at this. ▪ But still do not provide full and
▪ Filtering of phishing sites by immediate protection;
Browsers ▪ Transient Phishing sites that
▪ Users are warned, or prevented exist for just a few hours or a
from following, links to flagged day, remain problematic.

75
 Mitigating Phishing Attacks

▪ User Education is also useful

▪ Do not to click on arbitrary links in email messages
▪ Nor provide Sensitive Information on requests to “confirm” or
“verify” their account.
▪ However, with Social Engineering some users are drawn to
phishing sites
▪ Studies have shown that even security experts have great difficulty
distinguishing legitimate sites from fraudulent clones thereof
76
 Mitigating Phishing Attacks
Security Indicators
▪ Many users lack the strings that appear to denote
the domains they wish to visit,
patience to vigilantly e.g., [Link].
examine the domain string ▪ Attackers Exploit:
displayed in a browser URL ▪ Visual deception,
bar. ▪ Lack of user technical
▪ Similarly, some users do not background,
understand how domains are ▪ Limited attention for security
related to sub-domains subtasks
▪ Easily misled by subdomain

77
 Mitigating Phishing Attacks
Security Indicators

▪ Browsers have used a variety of Https-related Security

Indicators as visual cues, often located left of the URL bar
(location bar, web address).
▪ The most commonly used indicators have been
▪ A Closed Padlock Icon
▪ An https Prefix
▪ Assumed to be a useful signal to users with technical background

78
79
 Mitigating Phishing Attacks
Certificate Grades
▪ Certificate Authorities classify ▪ Organization Validation (OV)
digital certificates based on 3 ▪ Extra information on the
Organization associated with a
validation levels:
certificate Subject
▪ Domain Validation (DV)
▪ Extended validation (EV)
▪ Entirely automated (server-side)
▪ Sparsely used; Undergo Greater
and free from some providers
Scrutiny before issuance
▪ Acquisition is easy for Phishing
▪ Provide little benefit to end-
and other malicious sites
users, due to the inability of
▪ Has https but does not signal a browsers to convey to users
legitimate site differences from OV

80
 Lecture Outline | Progress
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security
 Usable Security

▪ Usable Security explores the design of secure systems

supporting both Usability and Security, rather than trading
one off against the other.
▪ Usable Security requirements: Browser Interfaces, Website Content
and Choices presented to users must be:
▪ Intuitive
▪ Simple
▪ Allow users to form a Mental Model consistent with avoiding dangerous
errors

82
83
 📝 To Study

▪ Summarize known security pitfalls of HTTP cookie

implementations
▪ Differences between the TLS and SSL
▪ Browser Plugins Vs Extensions
▪ What are the Differences
▪ What are their Benefits and Risks

84
 Lecture Outline | End
▪ Introduction HTTPS
▪ Web Review: Domains, URLs, ▪ HTTP Cookies and Session IDs
HTML, Scripts ▪ Same-Origin Policy
▪ Hypertext Transfer Protocol ▪ Web Security Attacks
▪ HTTP and Web Forms ▪ Cross-Site Request Forgery Attacks
▪ HTTP Referer Header ▪ Cross-site Scripting Attacks
▪ HTTP Proxies ▪ SQL Injection Attacks
▪ Browser (URL) Redirection ▪ Phishing Attacks
▪ Transport Layer Security and ▪ Usable Security