Anti Forgery Token Prevention

Anti-Forgery Token

It is help to prevent the CSRF attack, ASP.NET MVC uses anti forgery token.

1.       The client request HTML page contain a FORM.

2.       The server include two token in the response. One tone is the cookie, second token is palce in the hidden form field. Token are randomly generated not be guessable.

3.       When client submit the form, it must send both tokens back to the server.

4.       If request does not include both token server disallow the request.

<form action=”path” method=”post”>

<input name=”_requestverificationtoken” type=”hidden”

                                Value=”fhsdvjknsdfk634754795jnskdji8yh”/>

<input type=”submit” value=”submit”/>

</form>

Due to same origin policies malicious page can’t be read the token. Because of this anti forgery token works.

IN MVC

To add the anti-forgery tokens to a Razor page, use the HtmlHelper.AntiForgeryToken helper method

@using (Html.BeginForm("Manage", "Account")) {

    @Html.AntiForgeryToken()

}

CSRF(Cross Site Request Forgery)

Defense CSRF(Cross site request forgery)

1.       Check standard header to verify the request is the same origin

a.       The origin request is coming from (Source origin)

b.      The origin request is going to (target origin)

2.       Check CSRF token

d           Validate the cookie token and form token

Configure the webSEAL to validate the referrer header incoming HTTP request

Difference security terms

Phishing	Spoofing
Steal the information	Download malware to your computer or network
It is a method of retrieval	It is a mean of delivery
Phishing attack is use spoofing	Spoofing is not necessary
Steal the information	Not Steal the information

Vulnerability	Risk	Threat
Weakness in our Application	Potential for loss	Anything that is exploit
Vulnerability exist in our environment like design, coding, network	Risk is where vulnerability and threat	Threat is use where application is vulnerable

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.

Authentication Bypass Using HTTP Verb Tampering or Body Parameters

Many web server allow access control using HTTP Methods, enabling access using

  one or more methods.

The problem is that many configuration implementation ALLOW access to method that are not listed in access control, so control breach.

Apache .htaccess avoid “LIMIT” directive. Use “LimitExcept” directive.

JAVA EE avoid using <http-method> in access control policy.

ASP.NET use <deny verbs=”*” users=”*”/> after allowing the whitelist of required work.

Some more attribute to set in session and headers

Missing HTTP ONLY attribute in session cookie

<session-config>

<cookie-config>

<http-only>true</http-only>

</session-config>

</cookie-config>

CHECKS FOR SRI SUPPORT

Not supporting SRI

<script src="https://example.com/example-framework.js"

        crossorigin="anonymous"></script>

Supporting SRI

<script src="https://example.com/example-framework.js"

integrity="sha384-

oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC       

crossorigin="anonymous"></script>

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" />