On 07/11/2013 03:37 PM, Yoav Nir wrote: > I would still be able to make a form that would cause a POST. It's just a > matter of getting the user to click a button, no? I think I could also do it > in Javascript.
Which is why you need CSRF protection, as i mentioned.
>
> They don't have to. I don't think they wrote the web server from scratch.
> They have probably some web server and/or framework that does the cookie and
> authentication handling for them. CSRF counter-measures are hard. Writing the
> application with POST rather than GET is not hard, but it's something you
> have to think about. New-fangled cookies can be baked into the framework.
Any sane modern webapp framework has CSRF protection built in already.
Some not-so-sane and not-so-modern webapp frameworks have it too :P The
point is, the devs on this silly appliance you describe weren't using
such a framework.
> I think anything that takes the requirement for security clue away from the
> web developer and into the hands of the framework developer is a good thing.
> That does not mean they won't find other ways to mess up, but this is one
> case we can fix.
Sure, they could also have fixed it using standard tools that we already
have available, though, without any new standards.
I'm not saying that there are no good arguments for working on the
session continuation problem as stated; i'm just saying that this
example does not seem like a clear argument for it.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
