Web Application Security & Non-Hacking Tools & Techniques

Below are major threat categories. We'll study here different tools and techniques to prevent such attacks.

1. Cross Site Scripting(XSS) & HTML Injection 
2. Cross site request Forgeries(CSRF)
3. Session Hijacking
4. Injection
• SQL Injection
• HTML Injection
• HTTP header injection
• Mail-header injection
• OS command injection
5. Sensitive Data Handling
6. Phishing Attack
7. Click-Jacking
8. Directory Traversal
9. Race Condition
10. Access Control
11. Encryption
12. Programming
13. Input Validation

Security Vulnerability Tools: 

• Ref: https://phoenixnap.com/blog/vulnerability-assessment-scanning-tools
• Few :
• W3AF - Web Application Attack Framework - Free and open-source vulnerability scanning tool for web applications. It creates a framework which helps to secure the web application by finding and exploiting the vulnerabilities. Also has exploitation facilities used for penetration testing work as well. 
• Acunetix  - Paid web application security scanner (open-source version also available) with many functionalities provided. Around 6500 vulnerabilities scanning range is available with this tool. In addition to web applications, it can also find vulnerabilities in the network as well. Provides ability to automate your scan. HSBC, NASA, USA Air force are few industrial giants who use this for vulnerability tests.
• Intruder - Paid vulnerability scanner specifically designed to scan cloud-based storage. Intruder software starts to scan immediately after a vulnerability is released. The scanning mechanism in Intruder is automated and constantly monitors for vulnerabilities. Also identify network vulnerabilities as well as provide quality reporting and suggestions.

1). Cross Site Scripting(XSS):

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. 

• XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.
• An attacker can use XSS to send a malicious script to an unsuspecting user. 
• The end user’s browser has no way to know that the script should not be trusted, and will execute the script. 
• The malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. 
• These scripts can even rewrite the content of the HTML page.

Cross-site scripting (XSS) vulnerabilities occur when:

• Untrusted data enters a web application, typically from a web request.
• The web application dynamically generates a web page that contains this untrusted data.
• During page generation, the application does not prevent the data from containing ontent that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.
• A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
• Three Types of XSS:
• Type 1: Reflected XSS (or Non-Persistent) - The server reads data directly from the HTTP request and reflects it back in the HTTP response.
• Type 2: Stored XSS (or Persistent) - The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content.
• Type 0: DOM-Based XSS - In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection.

Security Solution:

1. No HTML tag should be allowed as input data
• ASP.NET Razor Views are HTML Encoded by default (also ASP.NET MVC 4)
• For aggressive stripping use Microsoft AntiXSS library
• Use HTML.Encode <%: %> provided by ASP.Net MVC for output
2. All inputs should be HTML escaped
• Prevent HTML tags in inputs by default, globally. (To turn it off - ValidateInput=false / AllowHTML) (ASP.NET MVC 4)
• Use Microsoft Anti-Cross Site Scripting Library (AntiXSS) and set it as default HTML encoder.
• Use AntiXSS Sanitizer object to call GetSafeHtml or GetSafeHtmlFragment before saving HTML data to the database
3. All attributes should be put  in double quote parentheses
4. Ensure no Script tag is included in the input value
5. Specify the charset  to Content Type on HTTP response header
• Modify web.config code on IIS with following to specify charset and content-type as (name="Content-Type" value="text/html; charset='UTF-8'" )
6. Use HttpOnly attribute to the cookie
7. Use of AllowHtml Attribute in MVC
8. Encode HTML Tags - 
1. Encode the string input using HtmlEncode method. 
2. Write a Regular Expression to replace HTML tags by replacing its encode character
9. Enable ASP.NET request validation - Either ValidateRequest="true"or remove the ValidateRequest page attribute 

2). Cross site request Forgeries(CSRF):

CSRF vulnerabilities occur when:

• When attacker tricks the victim into submitting a malicious request by inheriting the identity and privileges of the victim to perform an undesired function on the victim's behalf. 

CSRF is an attack in which a user logs in to a website like ABC.com and after login user opens other site called malicious site in another tab, then this malicious site sends request to (ABC.com) valid site using existing credential or existing session for attacking the site. Valid site( ABC.com) assumes that this coming request is a valid request or coming from a valid user, so it executes that request and site is hacked by the CSRF.

A successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Security Solution:

1. In ASP.NET MVC:
• Client Side:
• Protect HTML form by using Html.AntiForgeryToken() inside the form. 
• @using(Html.BeginForm()) {
• @Html.AntiForgeryToken()
•  -- Rest of the form goes here.
• }
• This will render something like the following
• form action="/UserProfile/Edit" method="post" 
• input name="__RequestVerificationToken" type="hidden" value="B0aG+O+Bi/5..." 
• -- rest of form goes here --
• /form
• Using Html.AntiForgeryToken() will also give visitor a cookie whose name begins with __RequestVerificationToken.
• This cookie will contain the same random value as the corresponding hidden field. This value remains constant throughout the visitor’s browsing session and every request to server

• Server Side:

• Validate incoming form submissions by adding the [ValidateAntiForgeryToken] attribute to the target action method. Here’s an example:
• [ValidateAntiForgeryToken]
• public ActionResult Edit(string email, string hobby)
• {
• // Rest of code unchanged
• }
• This authorization filter ensure checking that the incoming request has a Request.Form entry called __RequestVerificationToken.
• And also ensure checking the request comes with a cookie of the corresponding name, and that their (I.e. Form field and Cookie) random values match.
• If not, it throws an exception (saying “a required anti-forgery token was not supplied or was invalid.”) and blocks the request.
• Else, request is pass thru and response is returned

• Note: The MVC Framework’s antiforgery system has a few other handy features:
• Antiforgery cookie’s name has a suffix that varies according to the name of your application’s virtual directory. This prevents unrelated applications from accidentally interfering with one another.
• Html.AntiForgeryToken() accepts optional path and domain parameters; these are standard HTTP cookie parameters that control which URLs are allowed to see the cookie. 
• For example, unless you specifically set a path value, the antiforgery cookie will be visible to all applications hosted on your domain (for most applications, this behavior is fine).
• __RequestVerificationToken hidden field value contains a random component (matching the one in the cookie), but that’s not all. 
• If the user is logged in, then the hidden field value will also contain their user name (obtainedfrom HttpContext.User.Identity.Name and then encrypted).
• [ValidateAntiForgeryToken] checks that this matches the logged-in user. This adds protection in the unlikely scenario where an attacker can somehow write (but not read) cookies on your domain to a victim’s browser and tries to reuse a token generated for a different user

3). Session Hijacking

In computer science, session hijacking, sometimes also known as cookie hijacking is the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a computer system.

Best way to prevent session hijacking is enabling the protection from the client side. It is recommended that taking preventive measures for the session hijacking on the client side. The users should have efficient antivirus, anti-malware software, and should keep the software up to date.

4). Click Jacking:

Clickjacking is an attack that tricks a user into clicking a webpage element which is invisible or disguised as another element. This can cause users to unwittingly download malware, visit malicious web pages, provide credentials or sensitive information, transfer money, or purchase products online.

A better approach to prevent clickjacking attacks is to ask the browser to block any attempt to load your website within an iframe. You can do it by sending the X-Frame-Options HTTP header.

//👇 new code

app.use(function(req, res, next) {

  res.setHeader('X-Frame-Options', 'sameorigin');

  next();

});

You configured an Express middleware that adds the X-Frame-Options HTTP header to each response for the browser. The value associated with this response header is sameorigin, which tells the browser that only pages of the same website are allowed to include that page within an iframe.

Hope this helps.

Regards,

Arun Manglick