Bugzilla is susceptible to multiple cross-site request forgery vulnerabilities as described at http://en.wikipedia.org/wiki/XSRF It is possible for an attacker to create hostile pages that embed (via hidden iframes or images) requests to administrative bugzilla pages that will be silently executed with the credentials of any bugzilla user or administrator who visits them. A simple example that raises the privilege of a user on a bugzilla installation: <iframe style="display:none;" src="http://bugzilla.example.org/editusers.cgi?group_9=1&userid=5&action=update"></iframe> other attacks that exploit this vulnerability could be changing webdotbase via editprefs.cgi to effect a limited remote command execution on the bugzilla host, or adjusting the LDAP parameters to point to a hostile LDAP server that logs passwords of users who try to log in. This attacks works against (at least) editusers.cgi and editparams.cgi. The best solution for these vulnerabilities is to include a challenge key in each form that is generated from some private information and then validate it when the form is submitted back to the server. In bugzilla's case, a good challenge key could be based on the session ID, a per-user secret and a nonce as: challenge = (nonce, H(session_id, secret, nonce)) where H is some hash function like SHA1. Both the nonce and the secret should be be reasonably long (16-32 chars) and generated using a crypto-quality RNG like Crypt::Random. The nonce would need to be generated each time a form is displayed, but the per-user secret could be generated once when the user signs up. When a form is posted back to a bugzilla component, it can extract the nonce from the challenge, calculate H(session_id, secret, nonce) and verify that it matches what was posted. An attacker would not have access to the per-user secret and would therefore not be able to forge a response. They couldn't replay them either, because the challenges would be bound to the session. Note that converting the forms to use POST is not a solution, as this can be circumvented using javascript. Also, checking the HTTP Referrer header is not an adequate solution as this can be forged using flash (as described at http://ha.ckers.org/blog/20060725/forging-http-request-headers-with-flash/)

Ah, cross-site request forgery. I was wondering what people called it. *** This bug has been marked as a duplicate of 281181 ***

bug 281181 has been fixed.