WEB SECURITY
Web Security is very important nowadays. Websites are always prone to
security threats/risks. Web Security deals with the security of data over the
internet/network or web or while it is being transferred to the internet. For e.g.
when you are transferring data between client and server and you have to
protect that data that security of data is your web security.
Same-origin policy (SOP)
The same-origin policy is a critical security mechanism that restricts how a
document or script loaded by one origin can interact with a resource from
another origin.
Same-Origin Policy (SOP) is a rule enforced by web browsers, which controls
access to data between websites and web applications. Without SOP, any web
page would be able to access the DOM (Document object model) of other
pages. This would let it access potentially sensitive data from another web page
as well as perform actions on other web pages without user consent.
In web terms, the origin is a set of common characteristics of a web resource. In
most cases, the origin is a combination of three elements: the scheme (protocol),
the hostname (domain/subdomain), and the port.
Therefore, all resources identified by schema:hostname/anything:port have the
same origin. However, if even one of the three elements is different, modern
browsers such as Google Chrome or Mozilla Firefox consider the resources as
having a different origin.
For example, consider the following URL:
[Link]
This uses the scheme http, the domain [Link], and the port
number 80. The following table shows how the same-origin policy will be
applied if content at the above URL tries to access other origins:
URL accessed Access permitted?
[Link] Yes: same scheme, domain, and port
[Link] Yes: same scheme, domain, and port
[Link] No: different scheme and port
[Link] No: different domain
[Link] No: different domain
example/
[Link] No: different port*
It helps isolate potentially malicious documents, reducing possible attack
vectors. For example, it prevents a malicious website on the Internet from
running JS in a browser to read data from a third-party webmail service (which
the user is signed into) or a company intranet (which is protected from direct
access by the attacker by not having a public IP address) and relaying that data
to the attacker.
Why is the same-origin policy necessary?
When a browser sends an HTTP request from one origin to another, any
cookies, including authentication session cookies, relevant to the other domain
are also sent as part of the request. This means that the response will be
generated within the user's session, and include any relevant data that is specific
to the user. Without the same-origin policy, if you visited a malicious website, it
would be able to read your emails from GMail, private messages from
Facebook, etc.
SOP is not an Internet standard or a fixed rule but rather a general browser
security policy. It is interpreted differently by different browsers. It also works
differently for different technologies, for example, for cookies. However, the
general idea remains the same: to help make sure that there is not unauthorized
cross-site access.
CROSS-ORIGIN RESOURCE SHARING
(CORS)
The browser's same-origin policy blocks reading a resource from a
different origin. This mechanism stops a malicious site from reading
another site's data, but it also prevents legitimate uses. What if you wanted
to get weather data from another country?
CORS is a mechanism that allows a browser to load resources (such as web
fonts, images, etc) from servers in another domain other than their parent
domain. That is, unlike Same Origin Policy, CORS allows us
to securely access resources from other servers across the internet by using
additional HTTP headers to inform our browser to let our application have
access to resources on another domain (server).
Most of the browsers support CORS for the client side. But for servers,
CORS allows us to specify who can access the resources and how it could be
accessed.
However, it also provides potential for cross-domain attacks, if a website's
CORS policy is poorly configured and implemented. CORS is not a
protection against cross-origin attacks such as cross-site request
forgery (CSRF).
In a modern web application, an application often wants to get resources
from a different origin. For example, you want to retrieve JSON data from a
different domain or load images from another site into a <canvas> element.
In other words, there are public resources that should be available for
anyone to read, but the same-origin policy blocks that. Developers have
used work-arounds such as JSONP, but Cross-Origin Resource Sharing
(CORS) fixes this in a standard way.
Client request and server response
A browser and a server can exchange data over the network using
the Hypertext Transfer Protocol (HTTP). HTTP defines the communication
rules between the requester and the responder, including what information
is needed to get a resource.
The HTTP header is used to negotiate the type of message exchange
between the client and the server and is used to determine access. Both the
browser's request and the server's response message are divided into two
parts: header and body:
Header #
Information about the message such as the type of message or the encoding
of the message. A header can include a variety of information expressed as
key-value pairs. The request header and response header contain different
information.
Sample Request header
Accept: text/html
Cookie: Version=1
The above is equivalent to saying "I want to receive HTML in response.
Here is a cookie I have."
Sample Response header
Content-Encoding: gzip
Cache-Control: no-store
The above is equivalent to saying "Data is encoded with gzip. Do not cache
this please."
Body #
The message itself. This could be plain text, an image binary, JSON, HTML,
and so on.
CORS working process
The same-origin policy tells the browser to block cross-origin requests.
When you want to get a public resource from a different origin, the
resource-providing server needs to tell the browser "This origin where the
request is coming from can access my resource". The browser remembers
that and allows cross-origin resource sharing.
Step 1: client (browser) request #
When a domain is requesting to interact with a resource on another
domain, request headers are added from the first domain in order to use
the Cross-Origin Resource Sharing feature. These are the HTTP request
headers that may be associated with the requesting domain.
Origin
Access-Control-Request-Method
Access-Control-Request-Headers
Step 2: server response #
The domain who's resources are being requested can respond to the first
domain with the following HTTP response headers based on what
configuration options are set.
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Step 3: browser receives response #
When the browser sees this response with an appropriate Access-Control-
Allow-Origin header, the browser allows the response data to be shared
with the client site.
Vulnerabilities arising from CORS configuration issues
Many modern websites use CORS to allow access from subdomains and
trusted third parties. Their implementation of CORS may contain mistakes
or be overly lenient to ensure that everything works, and this can result in
exploitable vulnerabilities.
