What should be included in the ground rules for an attack review?

Question

I've drafted some ground rules for a call for adversarial attack-review. I've tried to cover the following topics:

1. Link to the policy that I want to enforce.
2. Link to a minimal testbed and installation instructions if that proves cumbersome.
3. Some suggestions on how to demonstrate an attack.
4. What an attacker might gain.
5. What is out of bounds -- things that, if attacked, will not result in credit.
6. How to disclose a vulnerability, claim credit, etc.
7. Pointers to fora for further questions.

What should a document like this cover? Anything I should add or leave out?

What in my specific draft (link above) is confusing, poorly thought out, or just plain boneheaded?

Answer 1

I think your document is great.

If you forced me to criticize something, I would mention two things:

1. Understanding the policy that you want to enforce takes some doing: it requires reading a bunch of code and regexps. I don't know if that's avoidable.

2. The attack scenario seems a bit limited. The ground rules don't seem to cover the case where the sanitized HTML fragment (e.g., from an eBay seller) is composed together with some trusted HTML (from eBay itself) to form a HTML document, and doesn't say what security properties must be enforced in this case. For example, in that kind of situation, the reader is forced to guess whether you are trying to protect the confidentiality of the rest of the page. If the sanitized HTML fragment can somehow discover the value of other secrets stored in the same document (e.g., CSRF tokens found in hidden form parameters in the trusted part of the document) and exfiltrate it, is that an attack? I suspect yes, it is.

But these are minor criticisms, and I think the ground rules posted are excellent.