[cap-talk] A palatable solution? (was: Plugging the YURL leak --back to the beginning)

[Rob J Meijer]

> On 12/2/05, Rob J Meijer <rmeijer at xs4all.nl> wrote:
>> > Unfortunately, this implementation falls to the same Confused Deputy
>> > attack I outline in:
>> >
>> > http://eros.cs.jhu.edu/pipermail/cap-talk/2005-December/004380.html
>>
>> I believe this scenario could be easily diverted by standard
>> http 'referer' header techniques.
>
> Could you provide more detail on how this standard technique works?
> For example, what should the server do if no Referer header is
> provided by the client? This will happen if the user uses a bookmark
> to access the URL, but could also happen in an attack scenario.
> Sending of a Referer header is an optional feature for an HTTP client
> and some clients can be configured to never send it.

The scenario described would I think be a simple XSS atack.
As I understand, many XSS and XSRF atacks can be diverted using the
folowing simple rules:

* Use POST, not GET when atributes are getting passed.
* Add some authentication or session bound hash to the html forms and
  validate it when processing the POST (XSRF).
* Use the HTTP referer field and make sure that its content
  matches a valid location where a form might reside (XSS).

The use of POST should prohibit any request containing atributes
from being thus bookmarked (this is a good thing I think).
It is important to check the referer when pressent and making
sure that the location where the atributes where requested
had an url that would logically refer to the URL being posted to.

Possibly the XSRF hash measure would further invalidate the use of the
XSS referer protection, but I understand they are commanly used both.

> I think there is also a danger that your design could devolve into an
> ambient authority design. Within a web page from the server, all of
> the user's authority is accesible via guessable URLs. If this web page
> contains content generated by another user, all of the recipient's
> authority is at risk. For example, if an attacker can introduce a FORM
> element into a server page, he can pre-populate it with the URLs for
> the authority he would like to receive from the other user. Similarly,
> introducing a javacript: URL into a web page served to another user
> would give you full access to that user's authority. Consider a secure
> wiki application like <https://yurl.net/id/home>. Under your proposed
> design, if a user put a javascript: link on a wiki page, he would gain
> access to the full authority of any user who views that page.
>
> Tyler

I think that if a POLA based design would even be unable to stop simple
XSS/XSRF atack scenario's, this would render it simply useless, and
would actualy do more bad than good to the POLA concept. If this means
reverting into simple technologies rooted in ambient authority based design,
than please lets do so. That doesn't mean you should not look for a more
pure/clean solution from a POLA design point of view, but if while looking
for that you temporary need to revert to other techniques just to
temporary
plug the hole, than at least you won't up with a POLA based design that
ends up being less secure than an ambient based alternatives.

Rob