UNIT 2

TRADITIONAL CLIENT SERVER

APPLICATION AND WEB APPLICATIONS
Understanding Vulnerabilities In Traditional
Client Server Application and Web Applications -
Client State Manipulation - Cookie Based Attacks
- SQL Injection - Cross Domain Attacks and Types
- Http Header Injection - Cross-Site Request
Forgery (CSRF).

2
 Introduction to web application
•Traditional client-server applications
•Traditional client-server applications are software systems
where the client software communicates with a server to
request services or resources.
•The server processes these requests and sends back responses.
Examples include desktop applications that connect to a
database server or email clients that interact with mail servers.

3
• Web application vulnerabilities involve a system flaw or
weakness in a web-based application. They have been
around for years, largely due to not validating or
sanitizing form inputs, misconfigured web servers, and
application design flaws, and they can be exploited to
compromise the application’s security.

4
Vulnerabilities in web applications differ from those in
traditional client-server applications
• Vulnerabilities in web applications often arise from their
distributed nature and reliance on web protocols and
technologies. Common web application vulnerabilities include
SQL Injection, Cross-Site Scripting (XSS), and Cross-Site
Request Forgery (CSRF).
• Traditional client-server applications, on the other hand, may
face vulnerabilities related to insecure communication
channels, weak authentication mechanisms, and local data
storage issues.
• Web applications are typically more exposed to public
networks, making them more susceptible to external attacks,
while client-server applications might face more internal
threats.

5
• To mitigate the risk of data interception in a
traditional client-server application that uses plain-
text communication, you can implement encryption
protocols such as SSL/TLS to secure the data
transmitted between the client and the server.
• This ensures that data is encrypted during transit,
making it difficult for attackers to intercept and read
sensitive information.

6
• Web applications often accept input from their users.
To be secure, web applications should not trust
clients, and should validate all input received from
clients. The protocol that web clients and web servers
use to communicate, HTTP, is stateless— web servers
are not required to implicitly keep track of any state,
or information, about their clients. Since HTTP was
originally developed to just serve documents, a web
client requests a document and the web server
(possibly with the help of a web application) provides
it

7
 Client-Side Vulnerabilities

• Bugs and Malware: Faulty code in the client software

can be exploited. Hackers might embed malware in
seemingly harmless files, compromising the user's
machine and potentially stealing data or launching
further attacks.
• Social Engineering: Tricking users into downloading
malicious files or revealing passwords through phishing
emails, fake websites, or social manipulation tactis.

8
• Cookies hacking, also known as session
hijacking, is a type of cyber attack where an attacker
intercepts or steals a user’s session cookie to gain
unauthorized access to their account or sensitive
information on a web application.

9
 Server-Side Vulnerabilities
• SoftwareBugs: Unpatched security holes in the server
software can allow attackers to gain unauthorized
access, manipulate data, or even take complete
control of the server.
• Weak Authentication: Simple password requirements
or lack of multi-factor authentication make it easier
for attackers to guess credentials and breach security.
• Insufficient Authorization: Even with valid login, users
might have access to unauthorized data or
functionality due to poorly configured access
10
• Web applications bring convenience and
interactivity to our fingertips, but they also
come with inherent vulnerabilities. Let's
explore some common weaknesses attackers
can exploit.

11
• Two common injection attacks are:
• SQL Injection: Hackers inject code that tricks the
database into revealing sensitive information or even
modifying it.
• Cross-Site Scripting (XSS): Hackers inject malicious
scripts into web pages. When a user views the page,
the scripts can steal their data, redirect them to
malicious sites, or disrupt the website's functionality

12
 Client State Manipulation in web Application Security
• In the world of web applications, keeping track
of users and their actions is crucial. This
information, often called client-state, is usually
stored on the user's side (the client) – think
cookies, hidden form fields, or session IDs in the
URL. But here's the catch: attackers can
manipulate this client-state to gain unauthorized
access or disrupt functionality.

13
Client State Manipulation in web Application Security
• collection of programs used by server to reply to
client (browser) requests .
• Often accept user input: don’t trust, validate!
• HTTP is stateless, servers don’t keep state
• To conduct transactions, web apps have state
• State info may be sent to client who echoes it back in
future requests

14
• Pizza Delivery Web Site Example Web app for
delivering pizza
• Online order form: order.html – say user buys one
pizza @ $5.50
• Confirmation form: generated by confirm_order
script, asks user to verify purchase, price is sent as
hidden form field
• Fulfillment: submit_order script handles user’s
order received as GET request from confirmation
form ( pay & price variables embedded as
parameters in URL)

15
16
• The Attack Scenario:
• Imagine you're shopping online and adding items to your cart.
The website stores the cart information in a hidden form field on
the page. A sneaky attacker could:
• View the Page Source: They might peek at the source code of the
webpage to see how the cart information is stored (often in
hidden form fields).
• Modify the Client-State: They could then change the values in
those fields, say, increasing the quantity of a high-priced item to
zero or even removing it entirely.
• Submit the Manipulated Data: Finally, they submit the altered
form, potentially getting a free or discounted item on your
behalf!

17
.
Impact:
• Client-state manipulation can have various negative
consequences:Unauthorized Access: Attackers can
manipulate login data (session IDs) to gain unauthorized
access to user accounts.
• Data Manipulation: They can tamper with data stored in
client-state, affecting everything from shopping carts to
financial transactions.
• Denial-of-Service (DoS): By manipulating data, attackers can
disrupt application functionality, causing crashes or
preventing legitimate users from accessing the
system.
18
 Protecting Against Manipulation
Here's how to fortify your web application against
client-state manipulation:
Minimize Client-Side Storage: Store as little
sensitive data as possible on the client-side. If you
must, use techniques like encryption or hashing to
make it harder to understand or modifY.

19
• Server-Side Validation: Always validate all user
input on the server-side, regardless of what the
client sends. Don't trust the data coming from
the user's machine!
• Use Secure Session Management: Employ secure
session tokens (like random, unpredictable
strings) and avoid storing sensitive information
like passwords in client-state.

20
• Consider Server-Side State Management: For
sensitive information, explore storing state on
the server and using techniques like session IDs
to link users to their data

21
 Cookie Based Attacks
• Cookies hacking, also known as session
hijacking, is a type of cyber attack where an
attacker intercepts or steals a user’s session
cookie to gain unauthorized access to their
account or sensitive information on a web
application.

22
• A session cookie is a small piece of data stored
by a web browser that keeps track of a user’s
session on a website, enabling the site to
remember the user’s preferences, login
information, and other settings.
• Once the attacker obtains a valid session cookie,
they can use it to impersonate the user,
potentially gaining access to sensitive
information or performing actions on the user’s
behalf without their consent.

23
• Cookie Hijacking Work:
• Session hijacking can be accomplished through
various methods, such as:
• • Packet sniffing: An attacker monitors
unencrypted network traffic to capture session
cookies being transmitted between a user’s
computer and the web server.
• •

24
• Cross-site scripting (XSS): The attacker exploits
vulnerabilities in a web application to inject
malicious scripts that steal session cookies from
a user’s browser.
• Man-in-the-Middle (MitM) attacks: The
attacker positions themselves between the user
and the web server to intercept and manipulate
communications, including capturing session
cookies.

25
• Social engineering: The attacker tricks the user
into revealing their session cookies through
phishing or other deceptive techniques.
• Physical access: An attacker with direct access to
a user’s device may be able to retrieve session
cookies from the browser’s cache or by using
malware

26
• Risks and Consequences of Cookies Hacking:
• Cookies hacking poses various risks and
consequences for both users and organizations,
such as:
• • Unauthorized access: An attacker with a
hijacked session cookie can gain unauthorized
access to a user’s account, potentially viewing,
modifying, or deleting sensitive information.
• •

27
• Identity theft: If an attacker gains access to
personal information such as names, addresses,
social security numbers, or financial data, they can
use it for identity theft or other fraudulent
activities.
• • Financial loss: Attackers may use hijacked
sessions to make unauthorized purchases, transfer
funds, or access financial accounts, leading to
financial losses for users or businesses.
•

28
• Reputation damage: Both individuals and
organizations can suffer reputational damage due
to session hijacking, as it may lead to the
unauthorized disclosure of private or sensitive
information or unauthorized actions being
carried out on behalf of the victim.
• Loss of privacy: Session hijacking can result in the
loss of privacy for users, as attackers may gain
access to personal messages, browsing history, or
other private data.
• •

29
• Legal consequences: Organizations that fail to
adequately protect user data or maintain proper
security measures may face legal consequences,
fines, or penalties due to data breaches or non-
compliance with privacy regulations.
Loss of productivity: Dealing with the session
hijacking attack can be time-consuming and costly
for both individuals and organizations, leading to
lost productivity as they work to remediate the
issue, recover lost data, or restore affected
systems.

30
 4 Ways to Protect Against Cookie Hacking
• Use HTTPS
• Rely on Web Frameworks for Session Cookie
Management
• Change the Session Key After Authentication
• Time Box User Sessions and Require Automatic
Logoff

31
 SQL injection
• SQL injection, also known as SQLI, is a common
attack vector that uses malicious SQL code for
backend database manipulation to access
information that was not intended to be
displayed. This information may include any
number of items, including sensitive company
data, user lists or private customer details.

32
 Impact of a successful SQL injection attack
• A successful SQL injection attack can result in
unauthorized access to sensitive data, such as:

• Passwords.
• Credit card details.
• Personal user information

33
• SQL injection attacks have been used in many
high-profile data breaches over the years. These
have caused reputational damage and regulatory
fines. In some cases, an attacker can obtain a
persistent backdoor into an organization's
systems, leading to a long-term compromise that
can go unnoticed for an extended period.

34
 How to detect SQL injection vulnerabilities

• You can detect SQL injection manually using a

systematic set of tests against every entry
point in the application. To do this, you would
typically submit

35
• The single quote character ' and look for errors
or other anomalies.
• Some SQL-specific syntax that evaluates to the
base (original) value of the entry point, and to a
different value, and look for systematic
differences in the application responses.

36
 SQL injection testing

• Boolean conditions such as OR 1=1 and OR

1=2, and look for differences in the
application's responses.
• Payloads designed to trigger time delays when
executed within a SQL query, and look for
differences in the time taken to respond.
• OAST payloads designed to trigger an out-of-
band network interaction when executed
within a SQL query, and monitor any resulting
interactions.

37
 SQL injection examples

• There are lots of SQL injection vulnerabilities, attacks, and

techniques, that occur in different situations. Some
common SQL injection examples include:

• Retrieving hidden data, where you can modify a SQL query

to return additional results.
• Subverting application logic, where you can change a
query to interfere with the application's logic.
• UNION attacks, where you can retrieve data from different
database tables.
• Blind SQL injection, where the results of a query you
control are not returned in the application's responses.
38
 cross domain attacks

• . A cross-domain attack is a malicious

attempt to trick users into visiting an infected
site that contains JavaScript that can perform
illegal operations on other domains. The
same-origin policy (SOP) is a security
mechanism that controls interactions between
two different origins and prevents malicious
domains from accessing cookies and tokens of
the attacked dom

39
 Types of cross domain attacks

• Cross-Site Scripting (XSS)

• Cross-Site Request Forgery (CSRF)
• Cross-Origin Resource Sharing (CORS)
• Cross-Domain Scripting (XDS):

40
 Http Header Injection

• The HTTP header injection vulnerability is a

web application security term that refers to a
situation when the attacker tricks the web
application into inserting extra HTTP headers
into legitimate HTTP responses..

41
• HTTP header injection is a technique that can
be used to facilitate malicious attacks such as
cross-site scripting, web cache poisoning, and
more. These, in turn, may lead to information
disclosure, use of your application in phishing
attacks, and other severe consequences

42
 HTTP header injection attack
HTTP header injection attacks are in many ways
similar to cross-site scripting (XSS) attacks. As
such, there are reflected HTTP header injection
attacks and (less common) stored HTTP header
injection attacks

43
• Reflected HTTP header injection
• Imagine that you are the owner of the example.com
domain and that an attacker wants to take advantage of
your HTTP header injection vulnerability described above.
They prepare a phishing campaign and send the following
URL:

• http://example.com/page1%0d%0aLocation:vulnweb.com
• As a result of the HTTP header injection, the CRLF
characters are inserted into the response and followed by
a new Location: header. The web browser (depending on
the browser type and configuration) will redirect the user
to the attacker’s site (here: vulnweb.com).
44
 Stored HTTP header injection

• Just like in the case of stored cross-site scripting

vulnerabilities, stored HTTP header injection is
more dangerous because it may potentially
affect all users that visit your website or use
your web application

45
Consequences of HTTP header injection attacks
• There are more potential consequences of
HTTP header injection. For example, the
attacker may use HTTP header injection to
inject new headers that loosen the same-
origin policy security restrictions, thus making
it possible to perform other attacks that would
otherwise be impossible, for example, CSRF

46
 How to detect and avoid HTTP header injection
vulnerabilities
The best way to detect HTTP header injection
vulnerabilities is to use a renowned web
vulnerability scanner such as Acunetix®. Acunetix
has tests for CRLF injection and specific tests for
HTTP header injection as well. Since the impact
of CRLF injection, in general, may be severe
(similar to the impacts of cross-site scripting),
these vulnerabilities should not be treated lightly
despite not being specifically mentioned in the
OWASP Top 10.
47
Cross-Site Request Forgery (CSRF).
• Cross-Site Request Forgery (CSRF), also known
as XSRF, Session Riding, or one-click attacks, is
a web security vulnerability that tricks a web
browser into executing an unwanted action on
a trusted site

48
• In a CSRF attack, an attacker assumes the
victim’s identity and uses it to perform actions
on behalf of the user. For example, a
successful CSRF attack can force a user to
transfer funds, change their email address, or
change their password. Attackers typically use
social engineering schemes to trick users into
executing these attacks.

49
 The Impact of CSRF Attacks
• When a website sends a data request to
another website on behalf of a user along with
the user’s session cookie, an attacker can
launch a Cross-Site Request Forgery Attack,
which abuses a trustful relationship between
the victim’s browser and the webserver.
• In some cases, depending on the type of
action, the attacker can gain full control of the
user’s account
50
Cross-site Request Forgery Work

51
 Methods of CSRF mitigation

• A number of effective methods exist for both

prevention and mitigation of CSRF attacks.
From a user’s perspective, prevention is a
matter of safeguarding login credentials and
denying unauthorized actors access to
applications.

52