0

I have a web interface to a hardware that is primarily used to reboot the hardware. Reboot can be done only by authenticated user.The web interface is written in CGI/shellscript. It does not use any session/cookies. It is one time authentication through lighttpd ldap authentication. No cookies are transferred on browser.

Can CSRF attack reboot the hardware? How can i find the CSRF vulnerability in such CGI/shell script web interfaces?

  • Have you checked for any CSRF protection? What is lighttpd ldap authentication? HTTP Basic Auth? If so, that can be vulnerable to CSRF. – David Jun 25 '14 at 3:42
  • yes basic mod_auth http authentication for light http.There is no CSRF protection.i ran owasp CSRFTester but it does not give any useful info. Is there any useful tool to find vulnerability – imanartist Jun 25 '14 at 3:48
2

CSRF can happen anytime your server services POSTs that don't originate from a form served by your server.

Not using cookies for authorization doesn't mean CSRF can't happen. An embedded iframe can still POST to any guessable URL with guessable parameters. A custom user-agent can still send guessable headers.

It is one time authentication through lighttpd ldap authentication.

I don't understand the details of this authentication method, but one-time usually solves the problem with CSRF. You won't be vulnerable to CSRF if

  • your reboot service always prompts the user to enter their credentials to do a reboot, then it is not by itself idempotent
  • the reboot service is only requested from a form with an unguessable action (e.g. one with an embedded secret or embedded credentials) from a page that checks LDAP
  • the reboot service only works when it has an unguessable header that is set by a page that checks LDAP then CSRF isn't a problem.
  • the reboot service is only reachable by an unguessable URL

† - more generally, any unsafe/side-effecting operation
‡ - more generally, not from code trusted by the origin that services the request

  • Thanks Mike. I checked the vulnerability manually, Reboot is vulnerable to CSRF beacuse it can be reachable by URL and does not prompt the user to enter credential every time.No other protection mechanism is der. – imanartist Jun 25 '14 at 13:19
  • @imanartist, Empiricism beats arm-chair security once again :) – Mike Samuel Jun 25 '14 at 13:22
  • 1
    +1. However, by non-idempotent I think you mean any operation with "side effects". Everything without side effects is idempotent, but not everything with side effects is non-idempotent. – SilverlightFox Aug 25 '14 at 14:04
  • @SilverlightFox, Good point. I suppose the HTTP DELETE method is idempotent if it succeeds silently when its target address does not refer to anything, and PUT is idempotent since it overwrites, but allowing DELETE and PUT cross-origin while disallowing POST would surprise many. Will edit. – Mike Samuel Aug 25 '14 at 14:13
  • @SilverlightFox, Does the safe method convention in RFC 7231#4.2.1 sound like the right term to you? – Mike Samuel Aug 25 '14 at 14:18

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.