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.

Session Hijacking Attack and Prevention

Session Hijacking:-

It is also known as TCP hijacking or cookie hijacking obtaining a session ID over the network. Once a session has been accessed the attacker that do anything as an authorized user. Session ID is normally stored in cookie and URL.

There are four main methods used to perpetrate a session hijack

Session Fixation, Attacker sending the email with a link that contains a particular session id. The attacker now only has to wait until the user logs in.

Session side-jacking, an attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Websites use SSL encryption for login pages to prevent attackers from seeing the password, but do not use encryption for the rest of the site once authenticated.

Cross-site Scripting, capture victim’s Session ID using XSS attack by using javascript.

Malware and unwanted programs can use browser hijacking to steal a browser's cookie files without a user's knowledge.

Prevent session hijacking

Encryption of the data traffic passed between the parties by using SSL/TSL

Use of a long random number or string as the session key. This reduces the risk that an attacker could not simply guess the session ID.

Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after s/he has logged in.

Some services change the value of the cookie with each and every request. This reduces the attacker impact.

The way to prevent session hijacking is enabling protection from client side. Most Time session hijacks from the client side. The users should have an efficient antivirus, anti-malware software, and should keep the software up to date.

Difference between multiple security terms

Encoding	Encryption	Hashing
Maintaining data usability	Maintaining data confidentiality	Validating the integrity of content
Reversed data by  employing same algorithm	Reversed data by  secret key	Validate through the signature
No secret key	Use key	Signature by a sender

SQL Injection	Blind SQL Injection
Display error message	Does not see an error message
It does not ask ant question	It ask a true and false question to database
Attacker see the result	Attacker not see the result

SQL Injection	Cross-Site Scripting
Inserting query syntax	Embedded script tags in URL
Attacker send simple text based syntax	Attacker send simple text based script
Injecting SQL field value in the form of regular expression	Simple HTML tags in the form of the regular expression
It can be easily effected	It can be affect with average vulnerability

Cross-Site Scripting	Cross-Site Request Forgery
It doesn’t need authentication	Authenticated Session
Escape the basic validating	Server trust the user
Need of java script	Not need of javascript
A site that is vulnerable to XSS attacks is also vulnerable to CSRF attacks	A site that is completely protected from XSS types of attacks is still most likely vulnerable to CSRF attacks.

Authentication Bypass Using HTTP Verb Tampering or Body Parameters

Many web server allow access control using HTTP Methods, enabling access using

  one or more methods.

The problem is that many configuration implementation ALLOW access to method that are not listed in access control, so control breach.

Apache .htaccess avoid “LIMIT” directive. Use “LimitExcept” directive.

JAVA EE avoid using <http-method> in access control policy.

ASP.NET use <deny verbs=”*” users=”*”/> after allowing the whitelist of required work.

Security Header

Below all headers are mitigating Cross-site scripting.

Content Security Policy Header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="Content-Security-Policy" value="default-src 'self';'unsafe-inline' 'unsafe-eval';" />

    </customHeaders>

  </httpProtocol>

</system.webServer>

X-Content-Type-Options header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="X-Content-Type-Options" value="nosniff" />

    </customHeaders>

  </httpProtocol>

</system.webServer>

X-XSS-Protection header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="X-XSS-Protection" value="1; mode=block"></add>

   </customHeaders>

  </httpProtocol>

</system.webServer>

Missing X-Frame-Scripting Header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

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

    </customHeaders>

  </httpProtocol>

</system.webServer>

Missing strict-transport-security header:-

system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains"/>

    </customHeaders>

  </httpProtocol>

</system.webServer>