Fundamentals of Cybersecurity

Chapter Five: Web Application Security

Senait Desalegn
School of Information Technology and Engineering
Addis Ababa Institute of Technology
Addis Ababa University
April 2025
Temesgen Kitaw Damenu
April 2022
Contents
Web application attacks and fundamental
protection methods
• Common web application attacks and fundamental protections
• OWASP top 10 vulnerabilities

Web security requirements

• Browser policies,
• Session management,
• User authentication

HTTPS and web application security

SiTE - AAiT - AAU 2

 Web application attacks

Common web application attacks

SiTE - AAiT - AAU 3

WWW: Years Back Vs Today
Years Back Today
❖The World Wide Web (WWW) ❖Majority of sites on the web are in
consisted only web sites, fact applications.
information repositories ❖Highly functional and rely on two-
❖One-way information flow, way flow of info between the
from server to browser. server and browser.
❖Security threats were related ❖The content presented to users is
to vulnerabilities in web server generated dynamically on the fly.
software. ❖Much of the information processed
❖Attacker would not gain access is private and highly sensitive.
to sensitive information, only ❖Security, therefore, is a big issue.
“The time
open info
is fast approaching when the only client
software that most computer users will need is a
SiTE - AAiT - AAU web browser”
Web and Security
❖The majority of web
applications are insecure,
despite the widespread
usage of SSL technology.
– Users can submit arbitrary input
to the server-side application.
– Users can interfere with any piece of
data transmitted between the client
and the server
– Users can send requests in any
sequence
SiTE - AAiT - AAU
Common web application attacks
❖Web application attack is any attempt to exploit
vulnerabilities on client or server in order to
– access sensitive information,
– perform unauthorized actions, or
– disrupt the normal functioning of the application
❖The most common attacks are
– SQL Injection
– Cross-site scripting (XSS)

SiTE - AAiT - AAU 6

SQL Injection
❖SQL injection is a code injection technique that exploits a
security vulnerability in a web application.
❖Inputting SQL statements in a vulnerable web form to perform
attack operations on the database.
❖A successful SQL injection exploit can:
– read sensitive data from the database,
– modify database data (Insert/Update/Delete),
– execute administration operations on the database (such as shutdown the
DBMS),
– recover the content of a given file present on the DBMS file system
– issue commands to the operating system.
SiTE - AAiT - AAU
SQL Injection: Bypassing a Login
❖Many applications use a database to store user
credentials and perform a simple SQL query such
as:
SELECT * FROM users WHERE username = ‘marcus’ and password =
‘secret’
– If an attacker knows that the username of the application
administrator is admin, he can log in as that user by supplying
any password and the following username: admin’--
– This causes the application to perform the following query:
SELECT * FROM users WHERE username = ‘admin’--’ AND password =
‘foo’
– Which is equivalent to:
SiTE - AAiT - AAU
SELECT * FROM users WHERE username = ‘admin’
SQL Injection: Bypassing a Login…
❖Suppose that the attacker does not know the
admin’s username.
❖Typically, the first account in the database is an
administrative user, because this account normally
is created manually.
❖An attacker can log in as the first user in the
database by supplying the username: ‘ OR 1=1--
❖This causes the application to perform the query:
SELECT * FROM users WHERE username = ‘’ OR 1=1--’ AND
password = ‘foo’
❖ Which
SiTE - AAiT - AAU is equivalent to:
SQL Injection: exploit vulnerable SQL
call

SiTE - AAiT - AAU

Injection Impacts More Than SQL
❖“Injection Flaw” is a blanket term
❖SQL Injection is most prevalent
❖Other forms:
– XPath Injection
– Command Injection
– LDAP (Lightweight Directory Access Protocol) Injection
– DOM (Document Object Model) Injection
– JSON (Javascript Object Notation) Injection
– Log Spoofing
–…

SiTE - AAiT - AAU

 Preventing SQL injection
❖Validate input
– Strong typing
• If the id parameter is a number, try parsing it into an integer
– Business logic validation
❖Escape questionable characters (ticks, --, semi-
colon, brackets, etc.)
❖Use prepared statements
– Instead of allowing the user to provide inputs, allow them to
choose from predefined list
❖Use the principle of least privilege
– If the query is reading the database, do not run the query as a user with
update permissions

SiTE - AAiT - AAU

Cross-Site Scripting (XSS)
❖Cross-site scripting
(XSS) is vulnerability
that enables attackers
to inject client-side
script into Web pages
viewed by other users.
– Their effect may range from a
petty nuisance to a significant
security risk.

SiTE - AAiT - AAU

Cross-Site Scripting (XSS)
Consequences
❖The most severe XSS attacks involve
– disclosure of the user’s session cookie, allowing an attacker to hijack the
user’s session and take over the account.
❖Other damaging attacks include:
– the disclosure of end user files,
– installation of Trojan horse programs,
– redirect the user to some other page or site, or
– modify presentation of content.
❖Some of XSS attack cases
– Websites of FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer,
Microsoft, Zdnet, Wired, and Newsbytes have all had XSS bugs.

SiTE - AAiT - AAU

Cross-Site Scripting (XSS)
Consequences…
❖Data residing on the web page can be sent anywhere in the
world
– Including cookies!
❖Facilitates many other types of attacks
– Cross-Site Request Forgery (CSRF), Session Attacks (more later)
❖Your site’s behavior can be hijacked

SiTE - AAiT - AAU

Preventing XSS Attacks
❖Identify every instance within the application where user-
controllable data is being copied into responses.
❖Then apply a three-fold approach:
– Validate input.
– Validate output.
– Eliminate dangerous insertion points.
❖Safely validate HTML input
❖Securing cookies:
– Matching cookies with IP addresses
– HTTPonly: make the cookie unavailable for client-side scripts
❖Disabling scripts
SiTE - AAiT - AAU
Preventing XSS Attacks…
❖Ensure your filter uses a white list approach
– Filters based on blacklisting have historically been flawed
• E.g. PHP, Ruby on Rails sanitize method
– New encoding schemes can easily bypass filters that use a blacklist
approach
❖Do not accept and reflect unsolicited input
– Reflecting every parameter for confirmation pages
– Printing out the session/request parameters in error pages

SiTE - AAiT - AAU

Cross Site Request Forgery (CSRF)
❖A CSRF attack forces a logged-on victim's browser to send a pre-
authenticated request to a vulnerable web application,
– which then forces the victim's browser to perform a hostile action to the
benefit of the attacker.
❖Occurs when an authenticated user unknowingly initiates a request
❖The request is handled as if it were intentional
– Usually happens without the user being aware!
❖CSRF attacks are difficult to track
– Commands are executed in the context of the victim
– The request comes from the users IP address so it is difficult to hunt
down the hacker
❖The hacker is essentially given all of the user’s privileges
❖XSS facilitates CSRF via “Link Injection”

SiTE - AAiT - AAU

CSRF Example
❖A hacker posts to a message board containing an image
tag
– <img src= “http://yourbank.com/transfer?
to_account=my_account_number&amount=all_of_your_money>
❖An unsuspecting user logs into yourbank.com and
authenticates
❖The user then visits said message board
❖A request is issued from the victim’s browser to the bank’s
website
❖The bank’s website transfers the user’s money to the
hacker’s account
SiTE - AAiT - AAU
CSRF Prevention
❖Add a secondary authentication mechanism
– Such as an impossible to guess token
❖Require a confirmation page before executing
potentially dangerous actions
❖Eliminate XSS vulnerabilities
❖Use POST as your form action and only accept
POST requests on the server for sensitive data !
– Incoming CSRF requests will fail since the parameter is in the URL
and not the post body
❖Architect your application to check authorization with
every request
SiTE - AAiT - AAU
 Web application attacks

OWASP top 10 vulnerabilities

SiTE - AAiT - AAU 21

 OWASP
❖Open Web Application Security Project
(OWASP)
– Nonprofit foundation dedicated to improving software
security
– Operates under an “open community” model, meaning
that anyone can participate in and contribute to
OWASP-related online chats, projects, and more
❖OWASP Top 10
– A standard awareness document for developers and
web application security
– Represents a broad consensus about the most critical
security risks to web applications
SiTE - AAiT - AAU 22
OWASP Top Ten
❖Identified
based on
Common
Weakness
Enumerations
(CWEs)
– A community-
developed list of
software and
hardware
weakness types
SiTE - AAiT - AAU 23
A01:2021 – Broken Access Control
❖Access control enforces policy such that users
cannot act outside of their intended permissions.
❖Failures typically lead to
– unauthorized information disclosure,
– modification, or destruction of all data or
– performing a business function outside the user's limits.

SiTE - AAiT - AAU 24

A01:2021 – Broken Access Control…
❖Common access control vulnerabilities include:
– Violation of the principle of least privilege or deny by default,
– Bypassing access control checks by modifying the URL
– Permitting viewing or editing someone else's account,
– Accessing API with missing access controls for POST, PUT and
DELETE.
– Elevation of privilege.
– Metadata manipulation,
– CORS misconfiguration allows API access from
unauthorized/untrusted origins.
– Force browsing to authenticated pages as an unauthenticated
SiTE - AAiT - AAUor to privileged pages as a standard user.
user 25
A02:2021 – Cryptographic Failures
❖The first thing is to determine the protection
needs of data in transit and at rest.
– For example, passwords, credit card numbers, health records,
personal information, and business secrets
❖For all such data:
– Is any data transmitted in clear text?
– Are any old or weak cryptographic algorithms or protocols used
either by default or in older code?
– Are default crypto keys in use, weak crypto keys generated or
re-used, or is proper key management or rotation missing? Are
crypto keys checked into source code repositories?
SiTE - AAiT - AAU 26
A02:2021 – Cryptographic Failures…
For all such data:
❖Is encryption not enforced?
❖Is the received server certificate and the trust chain properly
validated?
❖Are initialization vectors ignored, reused, or not generated
sufficiently secure for the cryptographic mode of operation?
❖Are passwords being used as cryptographic keys in absence of
a password base key derivation function?
❖Is randomness used for cryptographic purposes?
❖Are deprecated hash functions in use?
❖Are deprecated cryptographic padding methods in use?
❖SiTE
Are cryptographic
- AAiT - AAU error messages or side channel information
27
A03:2021 – Injection
An application is vulnerable to attack when:
❖User-supplied data is not validated, filtered, or sanitized by
the application.
❖Dynamic queries or non-parameterized calls without
context-aware escaping are used directly in the interpreter.
❖Hostile data is used within object-relational mapping (ORM)
search parameters to extract additional, sensitive records.
❖Hostile data is directly used or concatenated. The SQL or
command contains the structure and malicious data in
dynamic queries, commands, or stored procedures.
SiTE - AAiT - AAU 28
A03:2021 – Injection…
❖Some of the more common injections are
– SQL, NoSQL, OS command, Object Relational Mapping (ORM),
LDAP, and Expression Language (EL) or Object Graph
Navigation Library (OGNL) injection.
❖The concept is identical among all interpreters.
❖Source code review is the best method of
detecting if applications are vulnerable to
injections.

SiTE - AAiT - AAU 29

A04:2021 – Insecure Design
❖Insecure design is a broad category representing
different weaknesses,
– expressed as “missing or ineffective control design.”
❖An insecure design cannot be fixed by a perfect
implementation as by definition,
❖One of the factors that contribute to insecure
design is the lack of business risk profiling
inherent in the software or system being
developed,
– failure to determine what level of security design is required. 30
SiTE - AAiT - AAU
A05:2021 – Security
Misconfiguration
The application might be vulnerable if the
application is:
❖Missing appropriate security hardening across any part of the
application stack or improperly configured permissions on
cloud services.
❖Unnecessary features are enabled or installed (e.g.,
unnecessary ports, services, pages, accounts, or privileges).
❖Default accounts and their passwords are still enabled and
unchanged.
❖Error handling reveals stack traces or other overly
informative error messages to users.
SiTE - AAiT - AAU 31
A05:2021 – Security
Misconfiguration…
The application might be vulnerable if the
application is:
❖For upgraded systems, the latest security features are
disabled or not configured securely.
❖The security settings in the application servers, application
frameworks, libraries, databases, etc., are not set to secure
values.
❖The server does not send security headers or directives, or
they are not set to secure values.
❖The software is out of date or vulnerable

SiTE - AAiT - AAU 32

A06:2021 – Vulnerable and Outdated
Components
You are likely vulnerable:
❖If you do not know the versions of all components you use
(both client-side and server-side).
❖If the software is vulnerable, unsupported, or out of date.
❖If you do not scan for vulnerabilities regularly and subscribe
to security bulletins related to the components you use.
❖If you do not fix or upgrade the underlying platform,
frameworks, and dependencies in a risk-based, timely
fashion.
❖If software developers do not test the compatibility of
updated, upgraded, or patched libraries.
❖ If -you
SiTE do not secure the components’ configurations
AAiT - AAU 33
A07:2021 – Identification and Authentication
Failures
❖Confirmation of the user's identity,
authentication, and session management is
critical to protect against authentication-related
attacks.
❖There may be authentication weaknesses if the
application:
– Permits automated attacks such as credential stuffing, where the
attacker has a list of valid usernames and passwords.
– Permits brute force or other automated attacks.
– Permits default, weak, or well-known passwords, such as 34
SiTE - AAiT - AAU
A07:2021 – Identification and Authentication
Failures…
There may be authentication weaknesses if the application:
❖Uses weak or ineffective credential recovery and forgot-
password processes, such as "knowledge-based answers,"
which cannot be made safe.
❖Uses plain text, encrypted, or weakly hashed passwords
data stores.
❖Has missing or ineffective multi-factor authentication.
❖Exposes session identifier in the URL.
❖Reuse session identifier after successful login.
❖Does not correctly invalidate Session IDs.
SiTE - AAiT - AAU 35
A08:2021 – Software and Data
Integrity Failures
❖Software and data integrity failures relate to code
and infrastructure that does not protect against
integrity violations.
– An example of this is where an application relies upon plugins,
libraries, or modules from untrusted sources, repositories, and
content delivery networks (CDNs).
❖An insecure CI/CD pipeline can introduce the
potential for unauthorized access, malicious code,
or system compromise.
❖Many applications now include auto-update
SiTEfunctionality,
- AAiT - AAU 36
A09:2021 – Security Logging and Monitoring
Failures
❖This category is to help detect, escalate, and
respond to active breaches.
– Without logging and monitoring, breaches cannot be detected.
❖Insufficient logging, detection, monitoring, and
active response occurs any time:
– Auditable events, such as logins, failed logins, and high-value
transactions, are not logged.
– Warnings and errors generate no, inadequate, or unclear log
messages.

SiTE - AAiT - AAU 37

A09:2021 – Security Logging and Monitoring
Failures
❖Insufficient logging, detection, monitoring, and
active response occurs any time:
– Logs of applications and APIs are not monitored for suspicious
activity.
– Logs are only stored locally.
– Appropriate alerting thresholds and response escalation processes
are not in place or effective.
– Penetration testing and scans by dynamic application security
testing (DAST) tools do not trigger alerts.
– The application cannot detect, escalate, or alert for active attacks in
real-time or near real-time.
SiTE - AAiT - AAU 38
A10:2021 – Server-Side Request
Forgery (SSRF)
❖SSRF flaws occur whenever a web application is
fetching a remote resource without validating the
user-supplied URL.
❖It allows an attacker to coerce the application to
send a crafted request to an unexpected
destination,
– even when protected by a firewall, VPN, or another type of
network access control list (ACL).
❖The incidence of SSRF is increasing.
– Also, the severity of SSRF is becoming higher due to cloud
SiTE - AAiT - AAU 39
services and the complexity of architectures.
 Web application security
requirements

SiTE - AAiT - AAU 40

 Typical Web Setup
Apache
IIS
Nginx MariaDB
PostgreSQL
Request
PHP

PERL

Client PYTHON

OS/Web Server Database Server

Response Custom
Code

SiTE - AAiT - AAU 41

Key Focus
❖Confidentiality: This ensures that sensitive information is
neither made available nor disclosed to unauthorized
individuals, entities, or processes.
❖Integrity: This ensures that the information asset has not
been altered in an unauthorized manner.
❖Availability: This ensures that authorized entities or
processes have access to the application when required.
❖Authenticity: This ensures that an entity is who they claim
to be, and it guarantees the source from which the data
comes.
❖Traceability: This ensures that the actions of an entity can
SiTE - AAiT - AAU 42
be attributed exclusively to that entity.
Web application security
requirements
❖A security requirement is a statement of needed
security functionality
– that ensures one of many different security properties of software is
being satisfied.
❖Web application security requirements define
– new features or
– additions to existing features to solve a specific security problem or
– eliminate a potential vulnerability.

SiTE - AAiT - AAU 43

Web application security
requirements…
❖Web application security requirements are
derived from
– industry standards,
– applicable regulation (laws), and
– a history of past vulnerabilities.
❖OWASP Application Security Verification Standard (ASVS) is
among the industry stanards
– provides developers with a list of requirements for secure development
– provides a basis for testing web application technical security controls.

SiTE - AAiT - AAU 44

OWASP Application Security Verification
Standard (ASVS)
The requirements of ASVS were developed with the following
objectives in mind:
❖Use as a metric -
– Provide application developers and application owners with a yardstick
with which to assess the security of their Web applications,
❖Use as guidance -
– Provide guidance to security control developers as to what to build into
security controls to satisfy application security requirements, and
❖Use during procurement -
– Provide a basis for specifying application security verification requirements in
contracts.

SiTE - AAiT - AAU 45

OWASP Application Security Verification
Standard (ASVS)…
Focus areas ❖Error Handling and Loggi
❖Architecture, Design and ❖Data Protection
Threat Modeling ❖Communication
❖Authentication ❖Malicious Code
❖Session Management ❖Business Logic
❖Access Control ❖Files and Resources
❖Validation, Sanitization & ❖API and Web Service
Encoding ❖Configuration
❖SiTE
Stored
- AAiT - AAUCryptography 46
Web application security good
practices
❖Automate Your Release Process
❖Do (Thorough) Code Reviews
❖Test Your Code (to the Point of Boredom)
❖Anticipate Malicious Input
❖Neutralize File Uploads
❖Escape Content While Writing HTML
❖Be Suspicious of HTTP Requests from Other Sites
❖Hash and Salt Your Passwords
SiTE - AAiT - AAU 47
Web application security good
practices…
❖Don’t Admit Who Your Users Are
❖Protect Your Cookies
❖Protect Sensitive Resources (Even If You Don’t
Link to Them)
❖Avoid Using Direct File References
❖Don’t Leak Information
❖Use Encryption (Correctly)
❖Secure Your Dependencies (and Services)
SiTE - AAiT - AAU 48
Web application security good
practices…
❖Defuse Your XML Parser
❖Send Email Securely
❖Check Your Redirects (If You Have Any)
❖Don’t Allow Your Site to Be Framed
❖Lock Down Your Permissions
❖Detect and Be Ready for Surges in Traffic
Note: refer details of these good practices on:
Macdonald, M. (2022) Web security for developers: real
threats, practical defense
SiTE - AAiT - AAU 49
Browser Security
❖Web applications
– Online merchants, banks, blogs, Google Apps …
– Mix of server-side and client-side code
• Server-side code written in PHP, Ruby, ASP, JSP… runs on the Web server
• Client-side code written in JavaScript… runs in the Web browser
– Many potential bugs: XSS, XSRF, SQL injection
❖Web browser
– Responsible for securely confining Web content presented by visited
websites
•
Cookies
•
Isolation
•
Communication
•
Frames and frame busting
– Note: Cookies will be discussed here and there rest are reading assignments

SiTE - AAiT - AAU

Cookie Management
❖Cookies
– A cookie is a file created by an Internet site to store information
on your computer
Enters form data
Brow
ser Server
Stores cookie

Requests cookie
Brow
ser Server
Returns data

Http is stateless protocol; cookies add state

SiTE - AAiT - AAU

Cookie Management…
❖Cookie Ownership
– Once a cookie is saved on your computer, only the Web site that
created the cookie can read it.
❖Variations
– Temporary 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

SiTE - AAiT - AAU

Cookie Management…
❖Problems
– Cookies maintain record of your browsing habits
• May include any information a web site knows about you
– Sites can share this information
– Browser attacks could invade your “privacy”
❖Managing cookie policy via proxy
– Proxy intercepts request and response
– May modify cookies before sending to Browser
– Can do other checks: filter ads, block sites, etc.

SiTE - AAiT - AAU

Session Management
❖The communication between a web browser and a
website is usually done over HTTP or HTTPS.
❖When a user visits a website, a session is made
containing multiple requests and responses over HTTP.
❖Each request and response is independent of other
web processes.
❖Session management capabilities linked to
authentication, access, control, and authorization are
commonly available in a web application.

SiTE - AAiT - AAU

Authentication
❖User authentication is a method that keeps unauthorized
users from accessing sensitive information.
❖Cybercriminals can gain access to a system and steal
information when user authentication is not secure.
❖Authentication methods
– Password-based authentication
– Certificate-based authentication
– Biometrics authentication
– Token-based authentication
– Multi-Factor Authentication

SiTE - AAiT - AAU 55

 HTTPS and web application
security

SiTE - AAiT - AAU 56

SSL/TLS overview
Public-key encryption:
Alic Bo
m e b m
c c
Enc Dec

PKBob SKBob
• Bob generates (SKBob , PKBob )
• Alice: using PKBob encrypts messages and only Bob can
decrypt
SiTE - AAiT - AAU 57
SSL/TLS overview…
browse serve
r client- r
hello cert
server-hello + server-cert SK
(PK)
key exchange (several options): EC-DHE
RSA server-key-
exchange
client-key-
exchange
k Finishe k
d
HTTP data encrypted

SiTE - AAiT - AAU 58

SSL indicator: the lock icon

❖Intended goal:
• Provide user with identity of page origin
• Indicate to user that page contents were not viewed or
modified by a network attacker

SiTE - AAiT - AAU 59

SSL indicator: the lock icon…

When is the lock icon displayed?

❖All elements on the page fetched using HTTPS
❖For all elements:
• HTTPS cert issued by a CA trusted by browser
• HTTPS cert is valid (e.g. not expired)
• Domain in URL matches:
• CommonName or SubjectAlternativeName in cert
SiTE - AAiT - AAU 60
The lock UI: Extended Validation
Certs

❖Harder to obtain than regular certs

– requires human at CA to approve cert request
❖Helps block “semantic attacks”
❖HTTPS-EV and HTTPS are in the same origin

SiTE - AAiT - AAU 61

HTTPS and login pages: guideline

Users often land on login page over

HTTP:
❖Type HTTP URL into address bar
❖Google links to HTTP page
General guideline:
❖Response to
– http://login.site.com should be
https://login.site.com (redirected)
– E.g. http://www.combanketh.et/
redirected to
https://www.combanketh.et/
SiTE - AAiT - AAU 62
References
❖Macdonald, M. (2022) Web security for
developers: real threats, practical defense
❖OWASP (2021) Application Security Verification
Standard
❖OWASP (2021) OWASP Top Ten, Available on:
https://owasp.org/www-project-top-ten/

SiTE - AAiT - AAU 63

 Thank you!

SiTE - AAiT - AAU 64