1. XSS – Cross-site scripting vulnerability (XSS)
Parameter values sent by the client browser to the web application should be inspected enough by the server and an attacker can inject HTML or Javascript code instead of legitimate values. This vulnerability can be exploited by an attacker to carry out Cross-Site Scripting (XSS) in order to execute code in the victim’s browser. This vulnerability is often used to recover session cookies of a legitimate user in order to steal his session or to usurp his identity and his rights.
Recommendations:
Filter or encode every parameter sent to the application. For example: drop or escape special characters such as <, >, /, ‘, “ …
//To Encode scripts
public static string Encode(this string Instance)
{
return System.Web.HttpUtility.HtmlEncode(Instance);
}
public static string UriEncode(this string Instance)
{
return System.Uri.EscapeDataString(Instance);
}
//To Decode scripts
public static string Decode(this string Instance)
{
return System.Web.HttpUtility.HtmlDecode(Instance);
}
public static string UriDecode(this string Instance)
{
return System .System.Uri.UnescapeDataString(Instance);
}
2. Weakness in the management of rights
Ensure that all features or business functions are protected by an effective access control mechanism. A matrix should map user roles with features to avoid any unauthorized access. Do not assume that users will be unaware of special or hidden URLs or APIs. Implement an authentication process in order to protect sensitive resources or features against anonymous access.
Recommendations:
– Protect passwords by encryption or hash mechanisms.
-Ensure only POST calls to the server to avoid logging.
-Implement Industry Standard token-based authentication from the server.
-Check authorization based on the server token.
-Ensure that all parameters are encrypted before use.
-Cross-check calculations and selections from the client before saving transactions on the server.
3. Information Leak
Parameters can be passed to the dynamic websites via URL (GET method). Explicit and sensitive information may be present in these settings, such as the Active Directory domain(EXAMPLE), the user name (EXAMPLE), the user password, or information on software architecture. This information can be retrieved by observing the clear stream on the network or by observing the proxy server logs possibly located between the client and the server.
Recommendations:
– Ensure only POST methods to the server
-Only use encrypted passwords.
-Ensure no credit card information is passed via GET.
4. Cookie contains sensitive data
User credentials, such as logins and/or passwords, may be stored in the browser’s cookies. An attacker having access to these cookies may be able to steal the credentials and so spoof users’ identities on the service. Cookies can be retrieved for example on public workstations when a user forgets to log off, or through a cross-site scripting (XSS) attack.
Recommendations:
Changing to server-based cookies and tokens will eliminate the possibility of sensitive data in the cookies.
In order to maintain a user’s session across his browsing, cookies should only contain a randomly generated session identifier, which cannot be predicted. This kind of feature is already implemented in most web development languages and frameworks.
HttpCookie _Cookie = newHttpCookie(“CookieName”,”CookieValue”);
_Cookie .Expires=DateTime.Now.Add(7);
5. HttpOnly Option -Set HTTPOnly option in cookie
A cookie is a small piece of data sent from a website and stored in a user’s web browser while a user is browsing a website. When the user browses the same website in the future, the data stored in the cookie can be retrieved by the website to notify the website of the user’s previous activity. Cookies are typically used to store session identifiers in order to allow the user to browse the website without re-entering his credentials.
If the httpOnly optional flag optional is included in the server’s HTTP response header, the cookie cannot be accessed through the client-side script. As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser will not reveal the cookie to a third party.
As the server does not set the httpOnly flag to session cookies, users’ browsers create a traditional, script-accessible cookie. As a result, the session identifier stored in the cookie becomes vulnerable to theft or modification by malicious script.
Recommendations:
Set the httpOnly flag to session cookies in order to prevent any access from client-side scripts. As far as possible, renew session cookies for every request in order to prevent their exploitation by an attacker.
HttpCookie _Cookie = newHttpCookie(“CookieName”,”CookieValue”);
_Cookie .Expires=DateTime.Now.Add(7);
_Cookie.HttpOnly = true;
// Summary: Gets or sets a value that specifies whether a cookie is accessible by client-side script.
// Returns:true if the cookie has the HttpOnly attribute and cannot be accessed through a client-side script; otherwise, false. The default is false.
_Cookie.Secure = true;
// Summary: Gets or sets a value indicating whether to transmit the cookie using Secure Sockets Layer (SSL)–that is, over HTTPS only.
// Returns: true to transmit the cookie over an SSL connection (HTTPS); otherwise, false. The default value is false.
Have questions? Contact the software testing experts at InApp to learn more.
