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?

Improve this question
2
  • Have you checked for any CSRF protection? What is lighttpd ldap authentication? HTTP Basic Auth? If so, that can be vulnerable to CSRF. Commented Jun 25, 2014 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 Commented Jun 25, 2014 at 3:48

1 Answer 1

Reset to default
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

Improve this answer
6
  • 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. Commented Jun 25, 2014 at 13:19
  • @imanartist, Empiricism beats arm-chair security once again :) Commented Jun 25, 2014 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. Commented Aug 25, 2014 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. Commented Aug 25, 2014 at 14:13
  • @SilverlightFox, Does the safe method convention in RFC 7231#4.2.1 sound like the right term to you? Commented Aug 25, 2014 at 14:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.