On 18/07/10 10:03, Florian Apolloner wrote:
> On Jul 17, 11:29 am, Gregor Müllegger wrote:
>> I think Florian meant that its not possible to change HTTP headers by
>> Javascript XSS attacks (or am I wrong here as well?).
> Exactly.
I think you're thinking of CSRF, javascripted client-side parts o
On Jul 17, 11:29 am, Gregor Müllegger wrote:
> I think Florian meant that its not possible to change HTTP headers by
> Javascript XSS attacks (or am I wrong here as well?).
Exactly.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
I think Florian meant that its not possible to change HTTP headers by
Javascript XSS attacks (or am I wrong here as well?).
Athor attacks that doesn't use a browser as their client can ofcourse
manipulate what is_ajax() returns.
To the actual proposal: I have the same opinion here as Florian. It
> This input field is easily fakeable. An attacker can't fake your
> browsers XHR requests, which makes request.is_ajax somewhat secure and
> trustable. I don't see how your solution could achieve that.
is_ajax() simply checks an HTTP header. It is easily set by an
attacker.
On Jul 16, 2:30 pm, F
Hi,
On Jul 16, 7:25 pm, David De La Harpe Golden
wrote:
> People doing ajax have probably hit the "XMLHttpRequest doesn't do file
> uploads (at least not non-browser-specifically), use a hidden iframe
> kludge or flash" issue. Anyway, maybe that will change one day
It's already changing, modern
People doing ajax have probably hit the "XMLHttpRequest doesn't do file
uploads (at least not non-browser-specifically), use a hidden iframe
kludge or flash" issue. Anyway, maybe that will change one day, but
right now:
Things that try to handle file uploads via hidden iframes, like the
jquery-for