0% found this document useful (0 votes)
28 views117 pages

Ch07 Web Security

Gguikoo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views117 pages

Ch07 Web Security

Gguikoo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 117

Web Security

Md. Shadmim Hasan Sifat


Lecturer,CSE-SUST
What could go wrong
with our web app?
• Our app could allow an attacker to view and/or
modify any information or perform any
operations we provide
• Leak information provided
• Perform actions on behalf of the user
• Our app could be used to attack anything on our
user's machine and or anything our user machine
can talk to
• If the user trusts us we can allow damage far
beyond what the user gives to us
• Security concept: Threat Model
• What attacks are we trying to deal with?
Security is a hard
problem

• Many opportunities for attackers


• Full stack means there are many interface
that an attacker can use
• Hard to identify all the vulnerabilities
• Complexity of system make it impossible
guarantee no vulnerabilities
• Even a small mistake can compromise entire
application
• Only as strongest as the weakest link
Modes of attacks on web
applications
• Attack the connection between browser and
web server
• Steal password
• Hijack existing connection
• Attack the server
• Inject code that does bad things
• Attack the browser
• Inject code that does bad things
• Breach the browser, attack the client machine
• Fool the user (phishing)
Background
knowledge
Http and Html
Hypertext Markup Language (HTML)

• Hypertext markup language (HTML)


• –Describes the content and formatting of Web pages
• –Rendered within browser window
• HTML features
• –Static document description language
• –Supports linking to other pages and embedding images by reference
• –User input sent to server via forms
• HTML extensions
• –Additional media content (e.g., PDF, video) supported through plugins
• –Embedding programs in supported languages (e.g., JavaScript, Java) provides
dynamic content that interacts with the user, modifies the browser user
interface, and can access the client computer environment
HTML Tag
• Text formatting: such as <i>text</i>, for italics and <b>text</b>, for
bold

• Itemized lists: which list items set apart with bullets or numbers, such
as <ul> <li>first-item</li> <li>second-item</li> </ul>

• Hyperlinks: which provide ways to navigate to other web pages, such


as in <a href="web-page-URL"> Description of the other page</a>

• Scripting code: which describes various actions for the web page, such
as in <script>Computer code</script>

• Embedded images: such as in <img src="URL-of-an-image">


Web application architecture
Uniform Resource Locators (URLs)
• The process of visiting a website begins with the browser determining the
IP address of the web server that is hosting
• A web browser identifies a web site with a uniform resource locator, or
URL.
http://www.example.com/directory/file.html

• Here, www.example.com is the domain of the web server holding the web
site of interest, directory is the name of the folder that is storing the web
site of interest, and file.html is a file that describes the text and images for
a page on this web site
Connecting to a Web Server

• Given such a URL, the web browser first checks the local DNS cache on
its system for an entry corresponding to the domain of the web site being
requested.
• If no entry is found locally, the browser queries a DNS server to
resolve the IP address of the domain name.
• After the IP address of the web server is resolved, the client makes a TCP
connection to a specified port on the web server, which is, by default, port
80 for HTTP.
• Other protocols besides HTTP could also be used in a URL
• Port: 21 File Transfer Protocol (FTP)
Port: 80 Hypertext Transfer Protocol (HTTP)
Port: 443 Hypertext Transfer Protocol over TLS/SSL (HTTPS)
HTTP Request
• After establishing a TCP connection to the web server, the browser sends
requests, known as HTTP requests, to that web server, encapsulated in
the data portion of a TCP packet.
• HTTP requests typically begin with a request line, usually consisting of a
command such as GET or POST.
• Next is the headers section that identifies additional information.
• Finally, there may be more information provided in an optional message
body.
HTTP Request
GET VS POST
Request
More on get and post
GET POST
• GET requests can be cached • POST requests are never cached
• GET requests remain in the • POST requests do not remain in
browser history the browser history
• GET requests can be bookmarked • POST requests can not be
• GET requests should never be used bookmarked
when dealing with sensitive data • POST request have no restriction
• GET requests have length on data length
restrictions • POST requests is used to modify
• GET requests is only used to data
request data (not modify)
HTML Form
<form action="/product/update" method="post">
Product: <input type="text" name="product"/><br />
Deluxe: <input type="checkbox" name="delux" /><br />
<input type="submit" value="Submit"/>
</form>

• method="get" - Encode form properties as query params


HTTP GET product/update?product=foobar&delux=on
VS
• method="post" - Encode form properties as query params in message body
HTTP POST product/update
Content-Type: application/x-www-form-urlencoded
product=foobar&delux=on
HTTPS and
Certificate
Lack of Confidentiality in HTTP
• By default, HTTP requests and responses are delivered via TCP over port 80
• There are many security and privacy concerns with this default means of communication
• The standard HTTP protocol does not provide any means of encrypting its data
▪ That is, the contents are sent in the clear
• Because of this lack of encryption, if an attacker could intercept the packets being sent
between a web site and a web browser
▪ He would gain full access to any information the user was transmitting
▪ Could also modify it, as in a man-in-the-middle scenario
• This lack of confidentiality therefore makes HTTP inappropriate for the transmission of
sensitive information such as
▪ Passwords, credit card numbers, and Social Security numbers
• In addition, it is difficult to guarantee the identity of a web server using HTTP
▪ Are you really talking to correct web server or an attacker is simulating its behaviour.
Different Type of Attacks
Attacker has access to network communication between browser and server.

• Passive attacks:
• Eavesdrop on network traffic

• Active attacks:
• Inject network packets
• Modify packets
• Reorder, replay packets
• Block packets
Cryptography to the rescue
• Solution: use encryption to prevent eavesdropping and detect active attacks.
• Old idea: Scramble the information before transmitting it, unscramble when received
• Traditional encryption:
• Symmetric keys (same key on both ends)
• Key distribution problem: how can we exchange keys without meeting in person?

• Public-key encryption helps with the key distribution problem


• Each principal (user, program, etc.) has two encryption keys, one public, one secret
• Information encrypted with one can only be decrypted with the other.
• Encrypt with private key: Only principle can access
• Decrypt with public key: Know that it comes from principle
• Public-key encryption is slower than symmetric encryption
• Use public-key to exchange symmetric key
HTTPS
• To solve the confidentiality problem inherent in HTTP, an alternative protocol is
available called HTTPS (hypertext transfer protocol over secure socket layer).
• Incorporates an additional layer of security known as SSL (secure socket layer), or
a newer implementation, known as TLS (transport layer security).
• SSL and TLS rely on the notion of a certificate to verify
▪ the identity of the server
▪ establish an encrypted communication channel between the web browser and the web
server.
• Only one way:
• SSL/TLS does not allow the server to verify browser identity
Establishing a HTTPS session
• The browser requests an HTTPS session
with the server
▪ provides a list of cryptographic ciphers and
hash functions that the client supports
▪ The server chooses the strongest
cipher and hash function that are
supported by both the browser and
server, informs the browser of its choice
▪ The server sends back its certificate, which
contains the server’s public encryption key
▪ The browser then verifies the authenticity
of the certificate with the help of
trustworthy certificate authority.
Establishing a HTTPS session
• To complete the session, the browser encrypts a
random number using the server’s public key
• The server decrypts it using its private key using
this random number, the client and server generate
a shared secret
• The shared secret is used to
▪ Encrypt each subsequent message using a symmetric
encryption algorithm, satisfying confidentiality
▪ Provide integrity using MAC (Message Authentication
Code)
• Once all primitives are established
▪ Communication can be commenced using the normal
HTTP protocol
• A MAC is appended to each HTTP message and the
resulting authenticated message is encrypted
Comparison
Web Server’s Certificate
• Certificate authority:
• well-known, trusted server that certifies public keys like VeriSign.

• Certificate: a document encrypted with the secret key of a certificate


authority
• Identifies a particular service along with its public key

• Server can pass along this certificate to browsers


• Browser can validate the certificate came from the certification authority and see
who the certification authority thinks the browser is talking to.

• Trust: Browser trusts to certification authority


Digital Certificates
• In addition to providing a server’s public key for use in generating shared
secret keys, certificates provide a means of verifying the identity of a web
site to its clients
• To accomplish this goal, certificates are digitally signed using the private
key of a trusted third party, known as a Certificate Authority (CA)
• A web site owner obtains a certificate by submitting a Certificate Signing
Request to a CA and paying a fee
• After verifying the identity of the requester and ownership of the domain
name for the website, the CA signs and issues the certificate
▪ which the web server then sends to browsers to provide proof of its identity
• In short, a web server certificate is an attestation by the issuer (CA) of a
subject consisting of the organisation owning the web site, the domain
name of the web site, and the web server’s public key
Sample Certificate
• A web server certificate, also called SSL server
certificate, contains several fields, including:
• Name of the CA that issued the certificate
• Serial number, unique among all certificates issued by
the CA
• Expiration date of the certificate
• Domain name of the web site
• Organization operating the web site and its location
• Identifier of the public key crypto system used by the
web server (e.g., 1,024-bit RSA)
• Public key used by the web server in the HTTPS protocol
• Identifier of the cryptographic hash function and public
key cryptosystem used by the CA to sign the certificate
(e.g., SHA-256 and 2,048-bit RSA)
• Digital signature over all the other fields of the
certificate Since a web server provides its certificate as
part of the HTTPS protocol, most browsers provide a way
for a user to inspect a server’s certificate, as shown in
figure.
Certificate hierarchy
• How to verify the identity of the CA which signs a certificate?
▪ Utilise another certificate which is signed by another higher authority
• This creates a certificate hierarchy consisting of inter-mediate CA whose
certificate is signed by a CA
• In these cases, the top-level certificate is known as the root certificate
• Since the root certificate clearly cannot be signed by a higher authority, the root
certificate is known as a self-signed certificate, where the issuer is the same as
the subject
• A self-signed certificate essentially asserts its own legitimacy
• Root certificates are referred to as anchor points in the chain of trust used to
verify a certificate
• Such certificates are typically stored by the operating system or the browser in
protected files, in order to be able to validate certificates lower in the hierarchy
Trustworthiness and usability of certificates
• The contents of a certificate specify a validity period after which it expires and is no
longer considered as an acceptable verification of authenticity
• In addition to this built-in expiration date, a certificate includes the URL of a revocation
site, from which one can download a list of certificates that have become invalid before
their expiration date, called Certificate Revocation List (CRL)
• There are several reasons for a certificate to become invalid, including
▪ private key compromise
▪ change of organisation operating the web site
• When a certificate becomes invalid, the CA revokes it by adding its serial number to the
certificate revocation list, which is signed by the CA and published at the revocation site
• Checking the validity of a certificate involves not only verifying the signature on the
certificate, but also
▪ downloading the certificate revocation list
▪ verifying the signature on this list, and
▪ checking whether the serial number of the certificate appears in the list
Document Object Model
(DOM)
What is a Web site?
Javascript interface to HTML document
The Document Object Model (DOM)
▪ HTML document exposed as a collection of JavaScript objects and methods
• The DOM framework takes an object-oriented approach to HTML code,
conceptualizing tags and page elements as objects in parent-child relationships,
which form a hierarchy called the DOM tree
• JavaScript can query or modify the HTML document
• Rooted at window.document
• To indicate to a browser that Javascript is being used, the <script> and
</script> tags are used to separate sections of Javascript from ordinary
HTML code
Sample example

<script type="text/javascript"> <img src="picture.gif"


function hello() { onMouseOver="javascript:
alert("Hello world!"); hello()">
}
</script>
Common DOM Operations:
Change the content of an element
Change an <img tag src> attribute (e.g. toggle appearance on click)
Make element visible or invisible (e.g., for expandable sections, modals)
Redirect to a new page
Communicate with a user
Session and Cookie
Why use
sessions or
cookies?
Why use sessions or cookies?
• It is often useful for web sites to keep track of the behavior and properties
of its users.
• The HTTP protocol is statelesss, however, so web sites do not automatically retain
any information about previous activity from a web client
• When a web client requests a new page to be loaded, it is viewed by default as a fresh
encounter by the web server
• Session encapsulates information about a visitor that persists beyond the loading
of a single page
• several approaches for web servers to maintain session information for their
users
• Passing session information via GET or POST
• Maintaining cookies
• Implementing Server-side sessions management (some variables)
Sessions
• A sequence of requests and responses from one browser to one (or more)
sites
• the server generates a small segment of invisible code capturing the user’s
session information and inserts it into the page being delivered to the client
using the mechanism of hidden fields.
• Each time the user navigates to a new page, this code passes the user’s
session information to the server allowing it to “remember” the user’s state.
Session Tokens / Session IDs
Browser web site
GET /index.html
set anonymous session token
GET /books.html
anonymous session token
check
POST /do-login credentials
Username & password (crypto)
elevate to a logged-in session token

POST /checkout Validate


logged-in session token token
Session Token problem -> Solution
• particularly susceptible to man-in-the-middle attacks, unfortunately, since HTTP
requests are unencrypted.
• An attacker gaining access to the GET or POST variables being submitted
by a user could hijack their session and assume their identity.

• HTTPS must be used in conjunction with sessions implemented with GET or POST
variables to protect the user from these attacks.
• A typical mechanism for issuing sesssion IDs involves the use of a random number
generator or of a message authentication code(MAC).
Cookies
• uses small packets of data, called cookies, which are sent to the client by the web server
and stored on the client’s machine
POST …
Browser
Server
HTTP Header:
Set-cookie: NAME=VALUE ;
domain = (who can read) ;
If expires=NULL: expires = (when expires) ;
this session only
secure = (only over SSL)

Browser POST …
Server
Cookie: NAME = VALUE

HTTP is stateless protocol; cookies add state


HTTP Session via Cookie
• The name and content fields correspond
to the key-value pair of the cookie
• The domain name .paypal.com specifies
that this cookie is valid for this top-level
domain and all subdomains
• The path / indicates that it applies to the
root directory of the site
• The send for value indicates that this is
not a secure cookie
• The expiration date specifies when this
cookie will be automatically deleted
• If no expiration date is specified, the cookie
is deleted when the user exits the browser
Cookie authentication

Browser Web Server Auth server

POST login.cgi
Username & pwd Validate user

Set-cookie: auth=val auth=val


Store val

GET restricted.html
Cookie: auth=val restricted.html
auth=val Check val

If YES, YES/NO
restricted.html
Cookie Expiry
• If no expiration date is specified, the cookie defaults to being deleted
when the user exits the browser

if expires=NULL:
this session only
if expires=past date:
browser deletes cookie
Cookie security
• Cookies have profound implications for the security of user sessions
• For instance, it is dangerous to store any sensitive information unencrypted in
the body of a cookie, since cookies can typically be accessed by users of the
system on which they are stored
• Even if sensitive information is encrypted, however, accessing a user’s cookies for
a web site may allow an attacker to assume that user’s session
• Because of this, there is a need for users to protect their cookies as they would
any login information
• The expiration date built into cookies is a good preventive measure, but it is still
recommended that users erase their cookies on a regular basis to prevent such
attacks
• In addition to these security concerns, cookies also raise several issues related to
user privacy discussed later
Client Side
Attacks
Session hijacking

Phishing

As Web browser is an integral


part of the way people use
computers, they are the

Attacks on popular targets for attacks

URL obfuscation

Web Different kinds of attacks:

browser Privacy attacks

Cross Site Scripting (XSS)

Cross Site Request Forgery


(CSRF)
Session Hijacking
Server side sessions
• Servers typically use a session ID or session token —
a unique identifier that corresponds to a user’s
session.
• The server then employs one of the two previous
methods (GET/POST variables or cookies) to store
this token on the client side.
• When the client navigates to a new page, it
transfers this token back to the server, which can
then retrieve that client’s session information
• A session ID should be hard to guess by an attacker
• Thus, a typical mechanism for issuing session IDs
involves the use of a random number generator or of
a message authentication code
• if the client’s computer is ever compromised, then all
the attacker learns is an old session ID that is likely to
have expired by the time the attack occurs.
Predictable Tokens
Example 1: counter
⇒ user logs in, gets counter value,
can view sessions of other users
Example 2: weak MAC. token = { userid, MACk(userid) }
Weak MAC exposes k from few cookies.

Session tokens must be unpredictable to attacker

To generate: use underlying framework (e.g. ASP, Tomcat, Rails)

Rails: token = MD5( current time, random nonce )


Session Hijacking
Session Hijacking
• If the attacker is utilising a packet sniffer, then he might be able to
discover any session IDs that are being used by a victim
• Likewise, he might also be able to mimic session tokens encoded in
cookies or GET/POST variables
• Given this information, an attacker can hijack an HTTP session
• If an attacker can reconstruct a valid server-side session token, or
mimic a client-side token, then he can assume the identity of the
legitimate user with that token
• Thus, a first line of defence against HTTP session hijacking is to
protect against packet sniffers and TCP session hijacking
Replay Attack
• Attacks based on reusing old
credentials to perform false
authentications or authorizations.
• a replay attack would involve an
attacker using an old, previously valid
token to perform an attempted HTTP
session hijacking attack.
How to prevent Replay Attack
• To prevent session hijacking attacks in client-side tokens, it is important for
servers to encrypt session tokens
• In addition, it is also important for servers to defend against possible replay
attacks
• which are attacks based on reusing old credentials to perform false authentications or
authorizations
• Incorporating random numbers into client-side tokens, as well as server-side
tokens, and also by changing session tokens frequently, so that tokens expire
at a reasonable rate
• Associate a session token with the IP addresses of the client so that a session
token is considered valid only when connecting from the same IP address.
• One time password is also another approach to prevent replay attack
Phishing
Phishing
• Basic idea:
• Get unsuspecting users to visit an evil Web
site
• Convince them that the evil Web site is
actually a legitimate site (such as a bank or
PayPal)
• Trick the user into disclosing personal
information (password, credit card number,
etc.)
• Use the personal information for evil
purposes such as identity theft.
• hides its activity from the user, either by
redirecting them to the real site or
presenting a notice that the site is “down for
maintenance.”
• How to attract users?
Spoofing legitimate sites
How to spoof the legitimate site?
• Copy HTML
• Include images from legitimate Web site
• Many links refer back to the legitimate Web site
• After collecting login info, log user into legitimate site, redirect to legitimate site
• User has no idea that password has been stolen
Phishing attack
URL Obfuscation
URL Obfuscation
Or very subtly different: Look-alike
URL could be obviously Illegitimate characters
Won't user recognize a bogus address in the
URL bar?
• Many people won't notice the difference.
• Attacker can pick names that look similar to legitimate names:
• "vv" instead of "w"
• bankofthevvest.login.com VS bankofthewest.login.com
• Companies often use multiple names themselves (e.g., partners) so it's hard
to tell what is legitimate.
International Character Sets

• What does this URL refer to:

www.bank.com/accounts/login.php?q=me.badguy.cn

Chinese characters that look like "/", "?", and "="


• This is a host name only!
• www.paypal.com using the Cyrillic letter p, which has Unicode
value #0440,
instead of the ASCII letter p, which has Unicode value #0070.
Counter-measure: Visual Indicators
• Help users identify legitimate sites:
• Lock symbols to indicate HTTPS
• Color change to indicate HTTPS
Problems:
• Lock symbols not always obvious
HTTPS Indicators
Other counter-measures
• Browsers starting to include anti-phishing measures (warn users about known
phishing sites)
• Legitimate Web sites can monitor traffic; changes may indicate attacks under
way:
• Spike in download rates for official images
• Unusual rate of password changes, funds transfers
• Legitimate sites can incorporate personal information in emails to authenticate
them: phishers won't have such information.
• Spear phishing - Phishing with attacker having personal information
Click-Jacking
&
Click Fraud
Click Jacking
Click Jacking
• click-jacking is a form of web site exploitation where a user’s mouse click on a
page is used in a way that was not intended by the user.

<a onMouseUp=window.open("http://www.evilsite.com")
href="http://www.trustedsite.com/">Trust me!</a>

• it is possible for malicious sites to use other Javascript event handlers such
as onMouseOver
Click Fraud
• Click-jacking extends beyond the action of actually clicking on a page, since it is
possible for malicious sites to use other JavaScript event handlers such as
onMouseOver
• which triggers an action whenever a user simply moves their mouse over that element
• Another common scenario where click-jacking might be used is advertisement
fraud
• Most online advertisers pay the sites that host their advertisements based on the
number of click-throughs
• how many times the site actually convinced users to click on the advertisements
• Click-jacking can be used to force users to unwillingly click on advertisements,
raising the fraudulent site’s revenue, which is an attack known as click fraud
Cross Site Request Forgery (CSRF)
Cross-Site Requests
● When a page from a website sends
an HTTP request back to the
website, it is called same-site
request.
● If a request is sent to a different
website, it is called cross-site request
because the where the page comes
from and where the request goes are
different.

Eg : A webpage (not Facebook) can


include a Facebook link, so when users
click on the link, HTTP request is sent to
Facebook.
Cross-Site Requests and Its Problems
● When a request is sent to example.com from a page coming from example.com, the
browser attaches all the cookies belonging to example.com.
● Now, when a request is sent to example.com from another site (different from
example.com), the browser will attach the cookies too.

● Because of above behaviour of the browsers, the server cannot distinguish between
the same-site and cross-site requests
● It is possible for third-party websites to forge requests that are exactly the same as
the same-site requests.
● This is called Cross-Site Request Forgery (CSRF).
CSRF Attack : Prerequisites
• Victim must be logged in to target
website (a session must be active)
• Attacker must allure the victim to trust
the attacker’s website
• The target website does not have any
defence against CSRF.
Basic CSRF

• For launching CSRF on HTTP GET services, we can simply use HTML tags
instead of javascript
• Would work even if JS is disabled for untrusted websites on browser
CSRF: Countermeasures
• Very difficult to prevent, as to the websites, the request looks
legitimate
• Without a persistent cookie, use a session token and pass it with every
request
• The attacker needs to get hold of this session token to launch the attack
• However, different session tokens must be used for every session
• Also, don’t forget to log out after every session!
Cross Site Scripting (XSS)
Cross Site Scripting (XSS) Attack
Cross Site Scripting (XSS) Attack
Example: Attack on HTTP POST Service
• In persistent XSS, attacker script is stored on a persistent storage by
the vulnerable website’s server

• In non-persistent XSS, it is not stored


• Typically the input provided by the attacker is reflected on
another webpage (Example: search results page)
• If the input is not sanitized, XSS attack can be launched
Persistent XSS
• In a persistent XSS attack, the code that the attacker injects into the web
site remains on the site for a period of time and is visible to other users
• A classic example of persistent XSS is exploiting a web site’s guestbook or
message board
• Consider a web site, such as a news web site or social networking site, that
incorporates a guestbook allowing visitors to enter comments and post
them for other visitors to see
• If the user input to be stored in the guestbook is not properly sanitised to
strip certain characters, it may be possible for an attacker to inject
malicious code that is executed when other users visit the site
Example : Persistent XSS
Example : Non – Persistent (Reflective) XSS
Example : Non – Persistent (Reflective) XSS

• Attacker allures the victim to click on this URL


(clickjacking/spamming)
• Victim will visit the search results page, nothing will be seen on
the query field but the script will be executed
What Damages Can XSS Make?
Defenses against XSS
• Input sanitization
• Remove characters from input that potentially trigger code e.g. ‘<‘ or ‘>’

• Not allow untrusted websites to run scripts

• Filtering and detection


New Technique of XSS Attack
• Attackers adopting new techniques to prevent detection measures
• Using URL encoding to obfuscate detection measures
New Technique of XSS Attack
Safe-browsing practices
• Links to unknown sites, either contained in email or in the body of an
untrusted web site, should not be clicked on
• In addition, whenever entering personal information to a web site, a user
should always confirm that HTTPS is being used by looking for an indication
in the browser, such as a padlock in the status bar or colour coding in the
address bar
• Most financial sites will use HTTPS for login pages, but if not, the user
should manually add the “s” or find a version of the login page that does
use HTTPS
• In addition, the legitimacy of the site should be confirmed by examining
the URL and ensuring that there are no certificate errors
• And, of course, users should never provide sensitive information to an
unknown or untrusted web site
Built-in browser security measures
• Users should also be aware of a number of browser features that are
designed to prevent certain types of attacks
• Most importantly, each browser allows the customisation of settings
that allow fine-grained control over how different features are
allowed to run
• Internet Explorer introduces the notion of zones
• By default, web sites are placed in the Internet Zone
• Users can then delegate sites to Trusted and Restricted zones
• Each zone has its own set of security policies, allowing the user to have fine-
grained control depending on whether or not they trust a particular web site
Built-in browser security measures
• Most browsers also feature automatic
notifications if a user visits a web site that is on a
public blacklist of known phishing or malware
distributing sites
• Browser plugins, such as NoScript, use similar
white list and blacklist mechanisms, and can
attempt to detect XSS attacks and prevent cookie
theft by sanitising HTTP requests and scanning
the source code of a web site before execution
• Thus, users should take advantage of the built-in
browser security measures and make sure they
are running the most up-to-date version of their
browser, so that it has all the latest security
updates
Server Side
Attacks
Server Side Attacks

SQL INJECTION SERVER SIDE SCRIPTING DENIAL OF SERVICE


(DOS) ATTACKS
SQL Injection Attack (SQLi)
SQL Injection Attack
• Many web applications take user
input from a form
• Often this user input is used
literally in the construction of a
SQL query submitted to a
database
• For example: SELECT user FROM
table WHERE name = ‘user_input’;
• An SQL injection attack involves
placing SQL statements in the
user input
SQL Injection Attack : Example
SQL Injection Attack : Example
SQL Injection Attack : Example
SQL Injection Attack Example : Modify DB
SQL Injection Attack Example : Modify DB
SQL Injection Attack Example : Modify DB
SQL Injection Attack : Countermeasures
• Filtering and Encoding Data
• Data and code are still mixed together
• Escaping special character can be bypassed
SQL Injection Attack : Countermeasures
• Prepared statement in SQL databases
• Optimization feature
• Binary code is ready for template statement, bind parameters later
• Code part remains separated from data part
• Database knows the boundary between code and data
SQL Injection Attack : Countermeasures
Server Side Scripting
Server Side Scripting
• Server-side code, as its name suggests, is executed on the server,
and because of this only the result of this code’s execution, not the
source is visible to the client.
Server Side Scripting
• One of the more widely used general purpose server-side scripting
languages is PHP.
Server-Side Script Inclusion Vulnerabilities
• In a server-side script inclusion attack, a web security vulnerability
at a web server is exploited to allow an attacker to inject arbitrary
scripting code into the server.
• Web server executes this code to perform an action desired by the
attacker.
Server-Side Script Inclusion Vulnerabilities
• RFI (Remote-File Inclusion):
• Enables an attacker to execute a remote script in
another server

• LFI (Local-File Inclusion):


• Enables an attacker to execute a local malicious script
in the same server
Remote-File Inclusion (RFI) Attack

Fortunately, Most PHP installations now default to disallowing the server


to execute code hosted on a separate server
Local-File Inclusion (LFI)
Local-File Inclusion (LFI)
• LFI can be used with other vulnerabilities
• Example:
• Say web server also has upload mechanism without input
validation/sanitization
• Upload malicious code to cause privilege escalation
• Use LFI to execute that code
Web Server Privileges
• Whenever potentially untrusted users are added to the equation, it becomes
necessary to restrict privileges as tightly as possible so as not to allow malicious
users to exploit overly generous user rights.

• Following the general principle of least privilege, the web server application
should be run under an account with the lowest privileges possible.
• might only have read access to files within certain directories and have no
ability to write to files or even navigate outside of the web site’s root
directory.
• if an attacker compromised a web site with a server-side vulnerability, they
typically would only be able to operate with the permissions of the web
server, which would be rather limited.
DDoS Attacks To Web Servers
DDoS Attacks To
Web Servers
• A denial-of-service attack (DoS attack)
is a cyber-attack in which the
perpetrator seeks to make a machine
or network resource unavailable to its
intended users by temporarily or
indefinitely disrupting services of a host
connected to a network.

• In a distributed denial-of-service attack


(DDoS attack), the incoming traffic
flooding the victim originates from
many different sources.

You might also like