Condition of cross site scripting and solution

XSS:- It doesn't need an authenticated session and can be exploited when the vulnerable website doesn't do the basic validation or escaping input. Invulnerable website attacker sends text-based attack script that effects the application. Attacker XSS attack starts with simple HTML tag in the of a regular expression.
                                   The attacker injects the value in URL or Textbox. They run our script on the vulnerable website. The website reflects the error message through pop up.

Three type of XSS

Stored XSS Attack:- In the attacker inject the script and script stored permanently on the target server.

Reflected XSS Attack:- In this attacker inject the script and website thrown the error message.

DOM XSS Attack:- It generally involved in server site controller, script sent to the client but not sanitize.

Megitation:- 1. Understand all the potential areas where untrusted input inject

2. Specify character encoding like UFT-8

3. Input validation. Transform hazardous character into a character

Difference between multiple security terms

Encoding	Encryption	Hashing
Maintaining data usability	Maintaining data confidentiality	Validating the integrity of content
Reversed data by  employing same algorithm	Reversed data by  secret key	Validate through the signature
No secret key	Use key	Signature by a sender

SQL Injection	Blind SQL Injection
Display error message	Does not see an error message
It does not ask ant question	It ask a true and false question to database
Attacker see the result	Attacker not see the result

SQL Injection	Cross-Site Scripting
Inserting query syntax	Embedded script tags in URL
Attacker send simple text based syntax	Attacker send simple text based script
Injecting SQL field value in the form of regular expression	Simple HTML tags in the form of the regular expression
It can be easily effected	It can be affect with average vulnerability

Cross-Site Scripting	Cross-Site Request Forgery
It doesn’t need authentication	Authenticated Session
Escape the basic validating	Server trust the user
Need of java script	Not need of javascript
A site that is vulnerable to XSS attacks is also vulnerable to CSRF attacks	A site that is completely protected from XSS types of attacks is still most likely vulnerable to CSRF attacks.

Content security policy header

Currently, OWASP update the Header issue

To protect against Cross-Site Scripting, set the 'default-src' policy, or 'script-src' AND 'object-src' with proper values. Insecure values such as '*', 'data:', 'unsafe-inline', or 'unsafe-eval' should be avoided.

Protect against Cross-Frame Scripting or clickjacking, set the 'frame-ancestors' policy with proper values. Insecure values such as '*' or 'data:' should be avoided.

b     base-uri controls the protected resource’s ability to specify the document base URL.

       child-src deprecates and replaces frame-src, controlling the protected resource’s ability to embed frame

F     Form-action controls the protected resource’s ability to submit forms

       frame ansector controls the protected resource’s ability be embedded in other documents.

A protected resource’s ability to load Workers is now controlled via child-src rather than script-src

Content-Security-Policy: frame-ancestors 'self' example.com *.example.net ;

To prevent all framing of your content use:

Content-Security-Policy: frame-ancestors 'none';

To allow for your site only, use:

Content-Security-Policy: frame-ancestors 'self';

To allow for your site only, use:

Content-Security-Policy: frame-ancestors 'self';

<add name="Content-Security-Policy" value="frame-ancestors 'self' child-src 'self' *URL you website" />

Security Header

Below all headers are mitigating Cross-site scripting.

Content Security Policy Header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="Content-Security-Policy" value="default-src 'self';'unsafe-inline' 'unsafe-eval';" />

    </customHeaders>

  </httpProtocol>

</system.webServer>

X-Content-Type-Options header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="X-Content-Type-Options" value="nosniff" />

    </customHeaders>

  </httpProtocol>

</system.webServer>

X-XSS-Protection header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="X-XSS-Protection" value="1; mode=block"></add>

   </customHeaders>

  </httpProtocol>

</system.webServer>

Missing X-Frame-Scripting Header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="X-Frame-Options" value="SAMEORIGIN" />

    </customHeaders>

  </httpProtocol>

</system.webServer>

Missing strict-transport-security header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains"/>

    </customHeaders>

  </httpProtocol>

</system.webServer>

Clickjacking Attack and Prevention

Clickjacking:-

This type of attack requires an attacker to use javascript. Attacker insists a user perform an undesired action by clicking on a concealed link. The attacker loads another page on it in a transparent layer.

                                                                                                OR

The attacker hijacks the click event of their page and routing them to another page.

<HTML>

                <head>

                                <title>click</title>

                </head>

                <body>

                <p>website vulnerable clickjacking</p>

                <iframe src=”url” width=”500” height=”500”></iframe>

                </body>

</HTML>

Defend:-

Use clear click functionality in No script. You can use the relaxed setting but make sure you can enable the clear click. This prevents the clickjacking attacks.

Server-side: Sending the proper Content Security Policy (CSP) frame-ancestors directive response headers

The two most popular are X-Frame-Options: Deny and X-Frame-Options: SameOrigin.

Client-side: Most commonly use frame busting code typically consists of a "conditional statement" and a "counter-action" statement. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

Security Testing Procedure and Approaches

Security Testing

It is a type of software testing that checks whether the application or product is secured or not.

                                                Or

Security testing is performed to check whether there is any information leakage.

                                                Or

The goal of security testing is to identify the threats in the system and measure security risk.

                                                Or

Check the loopholes, weakness, and vulnerabilities of the web application.

                                                Or

Ensure that application is free from any loopholes or weakness.

Type of Security Testing

Vulnerability scanning: - This is done by the automated software to scan a system.

Security scanning: - Identify the network and system weakness and also provide the solution for reducing the risk.

Penetration Testing: - It is also known as pen test. Hacker malicious attack on the loophole or weakness of the system.

Risk Assessment: - Check the potential risk is either high or low. Analyze and evaluate the risk with the particular threats.

Security Auditing:-In this inspection of code line by line. It is a manual measurable technique of a system or application.

Ethical hacking:-It is systematical attempts to penetrate malicious script to exploit computer system or network on the behalf of the owner.

Procedure of web application security testing:-

1.       Scope of the application

2.       Check static and dynamic pages

3.       Identify the all login role of application

4.       Gather the information about the application

5.       Make profiling of the threats or security related test data.

6.       Security-related tools

7.       Test according to the threats profiling

8.       Scan application according to the threats profiling

9.       Report creation

Report submission

Approaches of web application security testing

·         Passive Approach- Actions taken to monitor the security

·         Understand the logic of the application

·         Information Gathering

·         Understand all the login role of the application

·         Active Approach-Covers all actions designed to prevent a breech

·         Configuration Management Testing.

·         Testing for file extensions which is a need or not need

·         Test file name without script tag

·         Test old, backup, temporary file not be left

·         Testing for HTTP methods

·         Testing for the business logic of the application

·         Testing for XSS(cross-site scripting)

·         Testing for SQL injection

·         Authentication Testing

·         Credentials transport over an encrypted channel

·         Testing false login credential to account lockout

·         Brute Force Testing

·         Testing for bypassing authorization schema

·         Session Management Testing

·         Test all headers for mitigating the XSS and CSRF

·         Testing for Cookies attributes- http only, secure and time validity

·         Testing for CSRF(cross-site request forgery)