Le 4 févr. 2015 à 03:31, Jon Dufresne a écrit :
>
> Prevent the application from being served in an attacker's iframe: use
> X-Frame-Options. (Supported by all major browsers [1])
That's irrelevant in the scenario we're discussing here. The iframe Paul talks
about would be injected by a MITM. I
For the record, I'm not disagreeing with you. I don't know enough about the
topic to understand whether or not the referer check actually provides
another layer of security. I think the questions you're asking are good
ones.
Josh
On Wednesday, 4 February 2015 15:11:34 UTC+11, Jon Dufresne wrot
On Tue, Feb 3, 2015 at 7:09 PM, Josh Smeaton wrote:
> Just quickly, HSTS[0] and X-Frame-Options[1] are supported and recommended
> in the security documentation already. As you point out though, HSTS isn't
> yet a full solution, and, frankly, it scares me a little. Personally, I
> redirect the / p
Just quickly, HSTS[0] and X-Frame-Options[1] are supported and recommended
in the security documentation already. As you point out though, HSTS isn't
yet a full solution, and, frankly, it scares me a little. Personally, I
redirect the / path to HTTPS from HTTP and drop all other HTTP connections
On Tue, Feb 3, 2015 at 2:12 PM, Paul McMillan wrote:
> The referer check is primarily there to help make users who choose not
> to use HSTS safer.
>
> Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP
> page emulating your domain in an iframe on a different unencrypted
> page, eve
If we add Origin checking, could we then allow a missing referrer and
token? (check referrer and token if no origin header)
On Tuesday, February 3, 2015 at 5:15:08 PM UTC-5, Paul McMillan wrote:
>
> The referer check is primarily there to help make users who choose not
> to use HSTS safer.
>
>
On Wed, Feb 4, 2015 at 6:49 AM, frantisek holop wrote:
> Tom Christie, 03 Feb 2015 12:53:
> > Trimming at `request.POST` or at the `Form` layer absolutely isn't
> > sensible, and a `normalize` argument is probably just overcomplicating
> > things, but I got the impression from that ticket that no
On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin wrote:
> Thank you both for the feedback. I will continue my analysis to understand
> django well and also try to contribute some patch on django if I can.
>
>
> For django URL dispatcher improvement I am also looking for some
> suggestions. Should I
Tom Christie, 03 Feb 2015 12:53:
> Trimming at `request.POST` or at the `Form` layer absolutely isn't
> sensible, and a `normalize` argument is probably just overcomplicating
> things, but I got the impression from that ticket that nobody would have
> any great issue with someone issuing a patch
The referer check is primarily there to help make users who choose not
to use HSTS safer.
Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP
page emulating your domain in an iframe on a different unencrypted
page, even if you only ever serve your own page from HTTPS), and then
post
On Tue, Feb 3, 2015 at 11:52 AM, Aymeric Augustin
wrote:
> You can fix that problem by saving some authentication info in the user's
> session, most likely with a custom auth backend — see django-sesame for an
> example of how to do this. Then redirect immediately to an URL that doesn't
> conta
On Tue, Feb 3, 2015 at 11:39 AM, Aymeric Augustin
wrote:
> Le 3 févr. 2015 à 16:54, Jon Dufresne a écrit :
>> Assuming this MITM already has the correct CSRF value, what is
>> stopping this MITM from adding a REFERER to the HTTPS request?
>
> While MITM of HTTP is trivial, MITM of HTTPS isn't pos
Trimming at `request.POST` or at the `Form` layer absolutely isn't
sensible, and a `normalize` argument is probably just overcomplicating
things, but I got the impression from that ticket that nobody would have
any great issue with someone issuing a patch with a `trim_whitespace` flag
on CharFi
On Tue, Feb 3, 2015 at 1:39 PM, Aymeric Augustin
wrote:
> Le 3 févr. 2015 à 16:54, Jon Dufresne a écrit :
>> Assuming this MITM already has the correct CSRF value, what is
>> stopping this MITM from adding a REFERER to the HTTPS request?
>
> While MITM of HTTP is trivial, MITM of HTTPS isn't poss
Le 3 févr. 2015 à 16:44, Jon Dufresne a écrit :
>
> However some URLs are accessed by a unique URL
> containing a nonce without a login. Login is not an option for these
> URLs. Sharing this URL is considered very bad and I would like to
> avoid it happening unintentionally.
You can fix that pro
Le 3 févr. 2015 à 16:54, Jon Dufresne a écrit :
> Assuming this MITM already has the correct CSRF value, what is
> stopping this MITM from adding a REFERER to the HTTPS request?
While MITM of HTTP is trivial, MITM of HTTPS isn't possible (under Django's
security model, which doesn't account for
Thank you both for the feedback. I will continue my analysis to understand
django well and also try to contribute some patch on django if I can.
For django URL dispatcher improvement I am also looking for some
suggestions. Should I also look to some tool like werkzeug, webob along
side django htt
Hi frantisek,
I've also ran into a number of problems with extra whitespace in forms.
Pretty annoying.
I also find settings pretty annoying. :) We were just talking on another
thread [1] about the possibility of packaging packaging django.forms as a
standalone package, but global settings are
good day,
a recent technical support incident conducted remotely and
involving a lot of back and forth of "huh? but i have entered
what you sent me" left me my head scratching.
the reason turned out to be a trailing space in the username of
the django admin loginform (thank god for nginx's "$requ
On Tue, Feb 3, 2015 at 6:18 AM, Aymeric Augustin
wrote:
> We're talking about a MITM of an HTTP connection that is then used for
> posting a form over an HTTPS connection. Check the comment in the first
> message of this thread for details.
Assuming this MITM already has the correct CSRF value, w
On Tue, Feb 3, 2015 at 1:31 AM, Aymeric Augustin
wrote:
> Your request boils down to "make Django's CSRF protection of HTTPS
> pages vulnerable to MITM attacks" which isn't acceptable.
Please. That is a very straw-man like way to have a discussion.
The first thing I asked for was for additional
2015-02-03 13:10 GMT+01:00 Tim Chase :
> On 2015-02-03 10:31, Aymeric Augustin wrote:
> > Your request boils down to "make Django's CSRF protection of HTTPS
> > pages vulnerable to MITM attacks" which isn't acceptable.
>
> If you've got a MITM that can intercept HTTPS, is there any reason to
> ass
On 2015-02-03 10:31, Aymeric Augustin wrote:
> Your request boils down to "make Django's CSRF protection of HTTPS
> pages vulnerable to MITM attacks" which isn't acceptable.
If you've got a MITM that can intercept HTTPS, is there any reason to
assume they aren't in a position to spoof DNS as well,
Hi Thomas,
Both ways had advantages and drawbacks. Eventually I chose to include only
the view function in the transaction for the following reasons.
1) Django never made any guarantees about which process_* methods of
middleware would be called. Therefore every middleware must implemented
defens
Hi Jon,
Your request boils down to "make Django's CSRF protection of HTTPS
pages vulnerable to MITM attacks" which isn't acceptable.
Of cours, if that's a tradeoff you want to make, you can make your own
version of CsrfViewMiddleware and put it in MIDDLEWARE_CLASSES.
2015-02-03 2:35 GMT+01:00 J
facepalm... Just read that on the contributing guidelines, didn't know that
won't fix bugs where never reopened. So I closed it as won't fix. If the
conversation keeps going I suppose a new bug will be opened.
On Tue, Feb 3, 2015 at 8:56 AM, James Bennett wrote:
> Please keep discussion going in
Dear Django developers,
we currently have the following issue when upgrading from Django 1.5 to Django 1.6:
https://github.com/etianen/django-reversion/issues/268
As it seems, since Django 1.6, middlewares are not supposed to be executed within the same transaction as the view
function is.
Please keep discussion going in this mailing-list thread, and keep in mind
Django's policies regarding re-opening a "wontfix" ticket (which are
essentially: don't do it).
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django its
Hi Jon,
I've reopened the bug so we have a new discussion. I think the things have
changed slightly in the last two years.
Thanks,
Raul
On Tue, Feb 3, 2015 at 2:29 AM, Karen Tracey wrote:
> This has bee brought up before, see:
> https://code.djangoproject.com/ticket/16870
>
> I am not aware of
Le lundi 2 février 2015 17:30:23 UTC+1, mattxbart a écrit :
>
> Hi all,
> I had a working 1.7.4 (using geodjango) on windows 7 install, no issues.
> I'm using osgeo4w to manage all the gdal/gis libraries. When I install the
> django 1.8a release or off git master, I get the following traceback:
>
30 matches
Mail list logo