Ovely permissive CORS

Origin header is sent by the browser in a CORS request and indicates that origin request. It may be spoofed outside the browser, so need to check that application-level protocols for protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response.

Insecure configurations as for example using '*' wildcard as value of the Access-Control-Allow-Origin header means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. This configuration is very insecure, and is not acceptable, except in case of a public API that is intended to be accessible by everyone.

add_header Access-Control-Allow-Origin $cors_header;

add_header Access-Control-Allow-Credentials true;

Insecure HTTP Methods Enabled

Attacker sends a request of type "OPTIONS" to the Web server of your application to determine what HTTP methods are supported by the server. Allow: HEAD, GET, PUT, POST, DELETE, TRACE, OPTIONS

The header Allow includes a list of supported HTTP methods.

Application is insecure if Allow header contains methods such as DELETE or PUT.

Web Application Source Code Disclosure Pattern Found

It is possible to retrieve the source code from server side script and also may possible to expose the business logic or sensitive information such as username and password.

Possible Causes

· Patches for 3rd. party products were not installed

· Temporary files were left in production environment

· Debugging information was left by the programmer in web pages

Application source code should not be accessible to web users, as it may contain sensitive application information and back-end logic.

It can give an attacker useful guidance for future exploitation. Leakage of sensitive information may carry various levels of risk and should be limited whenever possible.

Recommendation

There are many ways to revealing application source code. To ensure that your application does not allow web users access to source code. [1] Check that all system patches related to source code disclosure are installed. [2] Check that no application source code is left in HTML comments. [3] Check that all source code files are removed from the production environment

Security terms Salt, Nonce, Rainbow

Salt

A new salt (form of encryption) is randomly generated for each password. Setting a salt and a password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database.

Nonce

Nonce is an arbitrary number used only once in a cryptographic communication. It is a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

Rainbow

A rainbow table is a precomputed table. This table use for reversing cryptographic hash function, usually for cracking password hashes. Tables using for recover a plaintext password up to a certain length consisting of a limited set of characters. It take less computer processing time and more storage than a brute-force attack which calculates a hash on every attempt, but more processing time and less storage than a simple lookup table with one entry per hash.

Symmetric & Asymmetric Encryption

Symmetric Encryption

Symmetric encryption is the best-known technique. Use a secret key, which can be a number, word, or string of random letters, is applied on a message to change the content in a particular way. It is very simple as shifting each letter by a number of places in the alphabet. Both sender and recipient know the secret key, Secret key can encrypt and decrypt all messages.

Asymmetric Encryption

When secret keys is exchanging over the Internet might be going the wrong hands. After kept the secret key anyone decrypt the message. Solution is asymmetric encryption, in which there are two related keys--a key pair. A public key is easily available to anyone who want to send a message. A second, private key is kept secret, so that only you know it.

Encrypt message by using the public key can only be decrypt by applying the same algorithm, but by using the matching private key. If message encrypt by using the private key can only be decrypt by using the matching public key.

Validation Rule

You can add input validation to Web Forms pages by using validation controls.

To make sure that all the required parameters exist in a request, use the "RequiredFieldValidator" validation control. This control ensures that the user does not skip an entry in the web form.

To make sure user input contains only valid values, you can use one of the following validation controls:

[1] "RangeValidator": checks boundary value in between specified lower and upper boundaries. You can check ranges within pairs of numbers, alphabetic characters, and dates.

[2] "RegularExpressionValidator": checks that the entry matches a pattern defined by a regular expression. Validation allows to check for predictable sequences of characters, such as those in social security numbers, e-mail addresses, telephone numbers, postal codes, and so on.

Viewstate user key & Double submit cookie

CSRF Attack protection to all pages that inherit from the site.master page.

1. All web form pages data modification use the site.master page.

2. Al request data modification use Viewstste.

3. Website must be free from XSS vulnerabilities.

By using Microsoft . Net Protection Library

private const string AntiXsrfTokenKey = "__AntiXsrfToken";

private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";

private string _antiXsrfTokenValue;

protected void Page_Init(object sender, EventArgs e)

{

// The code below helps to protect against XSRF attacks

var requestCookie = Request.Cookies[AntiXsrfTokenKey];

Guid requestCookieGuidValue;

if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))

{

// Use the Anti-XSRF token from the cookie

_antiXsrfTokenValue = requestCookie.Value;

Page.ViewStateUserKey = _antiXsrfTokenValue;

}

else

{

// Generate a new Anti-XSRF token and save to the cookie

_antiXsrfTokenValue = Guid.NewGuid().ToString("N");

Page.ViewStateUserKey = _antiXsrfTokenValue;

var responseCookie = new HttpCookie(AntiXsrfTokenKey)

{

HttpOnly = true,

Value = _antiXsrfTokenValue

};

if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)

{

responseCookie.Secure = true;

}

Response.Cookies.Set(responseCookie);

}

Page.PreLoad += master_Page_PreLoad;

}

Anti-CSRF and AJAX

The Form token is make problem for AJAX request, Ajax is send the JASON data not a HTML form because of this form token not be validated in this form. So, the solution is send the token in a custom header in HTTP. Code use Razor syntax to generate the token, and add token in AJAX request. This token is generated by calling AntiForgery.GetTokens.

string cookieToken, formToken;

    Antiery.GetTokens(null, out cookieToken, out formToken);

    var responseCookie = new HttpCookie("__AJAXAntiXsrfToken")

    {

        HttpOnly = true,

        Value = cookieToken

    };

    if(FormsAuthentication.RequireSSL && HttpContext.Current.Request.IsSecureConnection)

    {

        responseCookie.Secure = true;

    }

    HttpContext.Current.Response.Cookies.Set(responseCookie);

    return formToken;

AntiForgery.Validate method validate the tokens and throws an exception if the tokens are not valid.

void ValidateRequestHeader(HttpRequestMessage request)

{

    string cookieToken = "";

    string formToken = "";

    IEnumerable<string> tokenHeaders;

    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))

    {

        string[] tokens = tokenHeaders.First().Split(':');

        if (tokens.Length == 2)

        {

            cookieToken = tokens[0].Trim();

            formToken = tokens[1].Trim();

        }

    }

    AntiForgery.Validate(cookieToken, formToken);

}