Introduction-to-Web-Application-Forensics

Introduction to Web Application Forensics

Introduction to Web Application Forensics in this the Web applications are programs that exist on a central server permitting a user, who visits a website via the Internet, to submit and retrieve data to and from a database. A web application makes a request through a web server. When the server responds to the request, the web application generates documents of the response for better client/user service. The web documents generated by web applications are in a standard format, i.e. HTML, XML, etc., which is supported by all types of browsers. Web applications accomplish the requested task irrespective of the operating system and browsers installed.

Despite having the advantage that the web applications possess, they tend to fall prey for attackers due to improper coding or security monitoring. The attackers try to exploit the vulnerabilities in the coding and gain access to the database contents, thereby gaining sensitive information, such as user credentials, bank account details, etc. Some of the attacks performed on the web applications include SQL injection, cross-site scripting, session hijacking, local and remote file inclusions, remote code execution, etc.

Related Product : Computer Hacking Forensic Investigator | CHFI

Web application forensics comes into picture when such kinds of attacks occur on web applications. The web application forensics involves forensic examination of web applications and its contents (such as logs, www directory, and config files) to trace back the attack, identify the origin of the attack, and determine how the attack was propagated along with the devices used (mobiles and computer) and the persons involved to perform the attack. The investigators examine the logs and configuration files associated with web server and application server, server side scripts used by the web application, and logs pertaining to third party software applications and operating system, to get an insight of the attack.

Web Application Forensics – Methodology and Practice

As to conduct a thorough analysis of the hacking attempt, it’s suggested that the investigator follow the methodology steps outlined here:

  1. Protect the web application (could be several servers) during forensics examination from any possible alteration or data corruption.
  2. Discover all files needed for the forensics investigation.

This includes:

  1. Web server(s) and application server(s) logs
  2. Server side scripts which are used by the web application
  3. Web server(s) and application server(s) configuration files
  4. Any 3rd. party installed software logs and vital files.
  5. OS logs and vital system files Remember that the files could also be cover several computer systems, which together comprise the web application.
  6. Analyze the collected data; attempt to create a particular chain of events. (techniques are going to be explained later)
  7. Summarize findings, and make a log of all files and data extracted from the web application.

Once this is often understood, the subsequent practices should be followed to make sure a comprehensive forensics procedure can take place:

  • Log file protection: As we’ve seen earlier during this paper, web application forensics is predicated mainly on log files and therefore the integrity of the info they contain. it’s highly recommended that you simply protect your log files, as any serious hacker will attempt to manipulate them.
There are several ways to guard the logs, such as:
  1. Setting the right permissions to the log files
  2. Keeping the log files out of the hacker’s reach. this will be done by using some kind of copy utility, which can save the log files on a remote server. (The copy routine should run briefly time intervals)
  3. Using some kind of checksum so as to verify the log files integrity
  • Collecting the evidence: If your web or application server doesn’t include the important log file entry fields needed for conducting the forensics investigation, you ought to use a 3rd party utility which does. we’ll see within the last section of this paper, how Sanctum’s AppShield logging facilities are often wont to retrieve this information easily and efficiently.
  • Divide and Conquer: During the investigation, attempt to divide the log file consistent with user sessions, e.g. if you’re using some kind of a session token, for instance a cookie, attempt to group log entries consistent with the token. The grouping will offer you better understanding of the session flow and timeline, and can remove noise created by other users within the log file. After the grouping is completed, you’re left with clusters of requests grouped consistent with the user or the originating IP address. Each cluster is organized internally consistent with the time that the request was made. The organized cluster describes the “User session flow”.
  • Digital fingerprints powder: Many attacks use ‘suspicious characters’, also mentioned as ‘hazardous characters’, which are easily spotted within the log files by the human eye, and sometimes by intrusion detection systems. Hackers often use anti-IDS techniques so as to hide the tracks made by the attacks. These techniques involve encoding of the suspicious characters using URL-encoding, or other sorts of encoding, which are supported by the online or application server (such as overlong UTF-8 – Unicode). it’s highly recommended that you simply use some kind of decoding script (‘digital fingerprints powder’) so as to assist you with the reading of the log file. But, you want to remember that you simply shouldn’t decode unreadable characters such as: \t \n \0 then on. they’re far more easily read in their encoded form – e.g. %09, %0d%0a and %00 respectively.
  • Intended application flow: Although it shouldn’t be considered reliable, the HTTP “Referer” header may sometimes help to verify that a user was following the intended application flow. for instance, if the primary page within the web application is /login.asp and right after it, the user is directed to the /account.asp page, once you see a request within the log file for /account.asp with the HTTP “Referer” header set to something else than “/login.asp” – you ought to be alerted.
  • Finding the digital fingerprints: several articles are written which describe the fingerprints and patterns left by web application hacking attempts. for instance, “Fingerprinting port 80 attacks: a glance into web server, and web application attack signatures” By Zenomorph http://www.cgisecurity.com/papers/fingerprint-port80.txt. it’s out of the scope of this paper to undertake and name all of the attack patterns, but it’s very easy to make a basic thumb rule, which describes most of them.

Also Read : Gathering Evidence from an IDS

When looking within the log files, any of the subsequent patterns should alert your attention:
  • Special characters (E.g. Meta-Characters like null byte, pipe ‘|’ and any string terminating characters like quote or apostrophe)
  • Bizarre or irregular HTTP Methods (E.g. PROPFIND, HEAD, PUT)
  • Binary utilities (E.g. cmd.exe in Win32 systems, or /bin/ls in Unix systems)
  • Vital system files (E.g. the SAM enter Win32 systems, or /etc/passwd in Unix systems)
  • Any files outside the web application directory
  • Any files outside the virtual web server root
  • Rapid/Massive requests to CGI scripts. this is often usually the case when hackers use CGI scanning automated utilities.
  • Extremely long requests (E.g. buffer overflow attempts – GET /AAAAAAA……)

Questions related to this topic

  1. What is forensic methodology?
  2. What is digital forensic methodology?
  3. How do you conduct effective investigation in digital forensics?
  4. What are the three best forensic tools?

This Blog Article is posted by

Infosavvy, 2nd Floor, Sai Niketan, Chandavalkar Road Opp. Gora Gandhi Hotel, Above Jumbo King, beside Speakwell Institute, Borivali West, Mumbai, Maharashtra 400092

Contact us – www.info-savvy.com

https://g.co/kgs/ttqPpZ

Leave a Comment