Log huntUnit 5 · Topic 5.6

Web server log hunt: spot the application attacks

Spot application attacks in a web server log.

New to this? Read the topic first: 5.6 Detecting Attacks on Data and Applications.

Simulation · [5.6.E.1, 5.6.E.2, 5.6.E.3, 5.6.E.4]

Web server log hunt: spot the application attacks

This is the access log of a library catalog web application. Each line shows the time and source internet protocol (IP) address, then the request and its HTTP status code. User input is shown decoded so you can read it. Tap every request that is an indicator of an application attack, then check.

access.log · catalog.library.example
  1. Fine. An ordinary search for a book title. Nothing unexpected in the input.

  2. Red flag. SQL injection: a single quote, the Boolean condition OR 1=1 and a double dash comment. All three are SQL control signs.

  3. Red flag. Directory traversal: the ../ sequences try to climb out of the covers directory to reach a file of database passwords elsewhere on the server.

  4. Fine. A normal request for a cover image inside the expected directory.

  5. Red flag. Stored XSS attempt: a script tag posted into a review that other visitors would load. 201 means the review was saved, so it needs removing.

  6. Fine. An ordinary search by author. No control characters, tags or ../ sequences.

  7. Red flag. Buffer overflow attempt: a query string far longer than any real username. The 500 error suggests the application struggled with it.

  8. Red flag. SQL injection: SQL control words in capital letters (SELECT, FROM) inside user input, trying to pull usernames and passwords.

Go to the topic: 5.6 Detecting Attacks on Data and Applications

Was this page helpful?

No names are ever shown, and every public comment is checked by us first. Please do not include personal details. To get a reply, email [email protected].

Course map
↑ Top

Enlarged view of the selected figure