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;

Query Parameter SSL

URL contain a sensitive query parameter and stored in the browser history. Web application may be configured log the URL of all request. So, result is sensitive parameter is saved in the log.

Fix:

The solution to this problem requires two steps:

· If necessary then pass sensitive data. Once a user is authenticated with a session ID limited lifetime.

· Use non-persistent, session level cookies to hold session IDs and other private data.

The advantage of using session level cookies to carry this information:

· They are not stored in the browsers history or on the disk

· They are usually not stored in server logs

· They are not passed to embedded resources such as images or javascript libraries

. They only apply to the domain and path for which they were issued

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.

Authentication and Authorization

· Authentication is the process of verifying who you are. When you log on to a PC with a user name and password you are authenticating.

· Authorization is after verifying that you have access to something. Gaining access to a resource because the permissions configured on it allow you access is authorization.

Authentication can be done using the following methods:

• Local Code42 platform directory
• LDAP
• Single Sign-On (SSO)
• RADIUS

Authorization can be done using the following methods:

· Local Code42 platform directory

• LDAP

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);

}