0% found this document useful (0 votes)
2 views

Document from Akhil

The document discusses the evolution of web applications from static pages to dynamic, interactive platforms that require user authentication and handle sensitive information. It highlights the security challenges associated with modern web applications, including vulnerabilities that can be exploited despite the use of SSL technology. Additionally, it provides an overview of HTTP requests and responses, including headers and their functions.

Uploaded by

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

Document from Akhil

The document discusses the evolution of web applications from static pages to dynamic, interactive platforms that require user authentication and handle sensitive information. It highlights the security challenges associated with modern web applications, including vulnerabilities that can be exploited despite the use of SSL technology. Additionally, it provides an overview of HTTP requests and responses, including headers and their functions.

Uploaded by

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

Web Application

Basics
The Evolution of
Web Applications
In the early days of the Web browsers were
Internet, the World invented as a means of
Wide Web consisted retrieving and
only of static displaying those
documents. documents.

The flow of interesting Most sites did not


information was one- authenticate users,
way, from server to because there was no
browser. need to

Each user was treated


Traditional website containing static information
in the same way and
was presented with the
same information.
The Evolution of
Web Applications

Security threats were related largely to


vulnerabilities in web server software

If an attacker compromised a web server, he


usually would not gain access to any sensitive
information, because the information held on the
server was already open to public view.

Rather, an attacker typically would modify the files


on the server to deface the web site’s contents.
Modern Web
Application
Today, the World Wide Web is almost unrecognizable
from its earlier form.

They are highly functional and rely on two-way flow


of information between the server and browser.

They support registration and login, financial


transactions, search etc.

The content presented to users is generated


dynamically on the fly and is often tailored to each
specific user.
Much of the information processed is private and
highly sensitive. Security, therefore, is a big issue.

Modern No one wants to use a web application if he believes


his information will be disclosed to unauthorized
Web parties.

Applicatio Web applications bring with them new and


n significant security threats.

Each application is different and may contain unique


vulnerabilities.
Hypertext Transfer Protocol
(HTTP)

Core communications protocol It was designed for Transmitting hypermedia HTTP is a stateless Protocol, HTTP can also be proxied and
used to access the World Wide communication between web documents, such as HTML. meaning that the server does tunneled over other protocols,
Web. browsers and web servers. not keep any data (state) allowing for secure
between two requests. communication
Web Application Security

• The most serious attacks against web applications are those that expose sensitive
data or gain unrestricted access to the back-end systems on which the application
is running.
• For many organizations, however, any attack that causes system downtime is a
critical event. Application-level denial-of-service attacks can be used to achieve
the same.

“This Site Is Secure”


Most applications state that they are secure because they use SSL. For example:

This site is absolutely secure. It has been designed to use 128-bit Secure Socket
Layer (SSL) technology to prevent unauthorized users from viewing any of your
information. You may use this site with peace of mind that your data is safe with us.
Web Application
Security

• In fact, most web


applications are
insecure, despite the
widespread usage of SSL
technology
Secure Sockets Layer (SSL)

• SSL is an excellent technology that protects the


confidentiality and integrity of data in transit between the
user’s browser and the web server.
• But it does not stop attacks that directly target the server
or client components of an application, as most successful
attacks do.
• Specifically, it does not prevent any of the vulnerabilities
just listed, or many others that can render an application
critically exposed to attack.
• Regardless of whether they use SSL, most web
applications still contain security flaws.
The Core Security Problem: Users Can Submit
Arbitrary Input

• Users can interfere with any piece of data transmitted between the client and the server,
including request parameters, cookies, and HTTP headers.
• Any security controls implemented on the client side, such as input validation checks, can be
easily circumvented.

Here are some examples of submitting crafted input


• Changing the price of a product transmitted in a hidden HTML form field to fraudulently
purchase the product for a cheaper amount
• Modifying a session token transmitted in an HTTP cookie to hijack the session of another
authenticated user

SSL does nothing to stop an attacker from submitting crafted input to the server. If the
application uses SSL, this simply means that other users on the network cannot view or modify
the data in transit
HTTP
Requests
• All HTTP messages (requests and responses)
consist of one or more headers, each on a
separate line, followed by a mandatory blank
line, followed by an optional message body.
• The first line of every HTTP request consists
of three items, separated by spaces.
1. A verb indicating the HTTP method. The
most commonly used method is GET
2. The requested URL
3. The HTTP version being used. The only
HTTP versions in common use on the
Internet are 1.0 and 1.1, and most
browsers use version 1.1 by default.
HTTP
Response
• The first line of every HTTP response
consists of three items, separated by
spaces:
1. The HTTP version being used.
2. A numeric status code indicating
the result of the request. 200 is
the most common status code; it
means that the request was
successful.
3. A textual “reason phrase” further
describing the status of the
response. This can have any value
and is not used for any purpose by
current browsers.
HTTP Headers
HTTP supports a large number of headers, some of which are designed for specific purposes.
Some headers can be used for both requests and responses, and others are specific to one of
these message types.
General Headers
• Connection tells the other end of the communication whether it should close the TCP
connection after the HTTP transmission has completed or keep it open for further messages.
• Content-Encoding specifies what kind of encoding is being used for the content contained
in the message body, such as gzip, which is used by some applications to compress
responses for faster transmission.
• Content-Length specifies the length of the message body, in bytes.
• Content-Type specifies the type of content contained in the message body, such as
text/html for HTML documents.
• Transfer-Encoding specifies any encoding that was performed on the message body to
facilitate its transfer over HTTP. It is normally used to specify chunked encoding when this is
employed.
HTTP Request Headers
Accept tells the server what kinds of content the client is willing to accept, such as image types, office document formats, and so on.

Accept-Encoding tells the server what kinds of content encoding the client is willing to accept.

Authorization submits credentials to the server for one of the built-in HTTP authentication types.

Cookie submits cookies to the server that the server previously issued.

Host specifies the hostname that appeared in the full URL being requested.

If-Modified-Since specifies when the browser last received the requested resource. If the resource has not changed since that time, the server may instruct
the client to use its cached copy, using a response with status code 304.
Origin is used in cross-domain Ajax requests to indicate the domain from which the request originated.

Referer specifies the URL from which the current request originated.

User-Agent provides information about the browser or other client software that generated the request.
HTTP Response Headers
Access-Control-Allow-Origin indicates whether the resource can be retrieved via cross-domain Ajax requests.

Cache-Control passes caching directives to the browser (for example, no-cache).

Expires tells the browser for how long the contents of the message body are valid. The browser may use the cached copy of this resource until this time.

Location is used in redirection responses (those that have a status code starting with 3) to specify the target of the redirect.

Pragma passes caching directives to the browser (for example, no-cache).

Server provides information about the web server software being used.

Set-Cookie issues cookies to the browser that it will submit back to the server in subsequent requests.

WWW-Authenticate is used in responses that have a 401 status code to provide details on the type(s) of authentication that the server supports.

X-Frame-Options indicates whether and how the current response may be loaded within a browser frame.

You might also like