Scribd
Upload
0 views1 page

Document 1

The document discusses the same-origin policy, which governs web security by allowing content from the same URI scheme, host name, and port number to share permissions. It explains how cross-site scripting (XSS) attacks exploit vulnerabilities to inject malicious scripts into trusted content, allowing attackers to access sensitive information. The term 'cross-site scripting' has evolved to include various forms of code injection beyond just JavaScript.

Uploaded by

b.nandhu2810
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0 views1 page

Document 1

The document discusses the same-origin policy, which governs web security by allowing content from the same URI scheme, host name, and port number to share permissions. It explains how cross-site scripting (XSS) attacks exploit vulnerabilities to inject malicious scripts into trusted content, allowing attackers to access sensitive information. The term 'cross-site scripting' has evolved to include various forms of code injection beyond just JavaScript.

Uploaded by

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

Abstract

Security on the web depends on a variety of mechanisms, including an underlying


concept of trust known as the same-origin policy. This essentially states that if
content from one site (such as https://mybank.example1.com) is granted
permission to access resources (like cookies etc.) on a web browser, then content
from any URL with the same (1) URI scheme, (2) host name, and (3) port number
will share these permissions. Content from URLs where any of these three
attributes are different will have to be granted permissions separately. Cross-site
scripting attacks use known vulnerabilities in web-based applications, their
servers, or the plug-in systems on which they rely. Exploiting one of these,
attackers fold malicious content into the content being delivered from the
compromised site. When the resulting combined content arrives at the client-side
web browser, it has all been delivered from the trusted source, and thus operates
under the permissions granted to that system. By finding ways of injecting
malicious scripts into web pages, an attacker can gain elevated access-privileges
to sensitive page content, to session cookies, and to a variety of other information
maintained by the browser on behalf of the user. Cross-site scripting attacks are a
case of code injection. Microsoft security-engineers introduced the term "cross-
site scripting" in January 2000.[3] The expression "cross-site scripting" originally
referred to the act of loading the attacked, third-party web application from an
unrelated attack-site, in a manner that executes a fragment of JavaScript
prepared by the attacker in the security context of the targeted domain (taking
advantage of a reflected or non-persistent XSS vulnerability). The definition
gradually expanded to encompass other modes of code injection, including
persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or
even HTML scripts), causing some confusion to newcomers to the field of
information security.

You might also like