2

I have tried CSRF attack on web vulnerability application known as DVWA at my localhost and on kali linux OS. I have changed password on this application by using CSRF. It has collected following log entries in access log.

127.0.0.1 - - [15/Dec/2018:22:01:21 +0530] "GET /DVWA/vulnerabilities/csrf/?password_new=abc123&password_conf=abc123&Change=Change HTTP/1.1" 200 4303

If any authenticated user will try to change the password, then same entries will be there in log file.

I want to know that what are be the common/expert features in log file which will identify that CSRF attack has been performed.

Note - I am doing log analysis in order to write an algorithm which will increase the accuracy in finding out the suspicious users through log file based upon the features of CSRF. I want help to find out the features. I have read this important link's information about CSRF features in Log file. Your help would be appreciated.

1

If you do not have CSRF protection in place, you can gather from the logs that a page has been spontaneously accessed, without going though an expected set of pages (each of them bringing in its CSRF token).

Unfortunately if your site is being scanned and walked though, this out-of-band approach will not work easily, and in that case the volume of queries may be an indication (possibly of an attack / reconnaissance, not of a CSRF attack specifically)

In other words, there are no clear indications of a CSRF attack being performed.

If you do have CSRF protection in place, it depends where the token is.

  • If it is in the body of the request (specifically, the headers) - you will not see it in the logs either.
  • If it is in the URL arguments, then you can search in the logs for URLs which do not have the token.
  • you have told these heuristic (possible) solutions to identify CSRF attack from log file. I want such more heurisic features. I am writing an algorithm for the same. Till the date I have done with XSS and SQLI. But I want some more help regarding CSRF. – Shree Dec 16 '18 at 20:35
  • 1
    @Shree: XSS and SQLi are arguably simpler in the sense that you are looking at an injection, that is someone is trying to send something which is relatively predictable (<script> and a whole lot of variants you can gather from OWASP cheat sheets). CSRF is different - the pages are accessed in a normal way (as you mentioned, proper user's logs will be the same), it is up to your server to decide whether they are expected by looking fro a token. Apache logs are before that and beside the token in the URL (rather unusual BTW) or suspicious volumes/sequences there i snot much more to do. – WoJ Dec 16 '18 at 20:40
  • it is the requirement of suspicious volume of CSRF attack features. The features should not be based upon one single database. Few coding may not contain that tokens. – Shree Dec 16 '18 at 20:45
0

I think it will be hard to find features that will be accurate enough to give you a low number of false positives (purely based on the default apache settings and without increasing logging).

The way we solved this before was to enable CSRF and to log any CSRF errors with their pages and the account that had the violation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.