Fwd: HTTP/2 and WSGI

[Russell Keith-Magee]

Hi all,

I have been contacted by Robert Collins, who is trying to get a working
group together to discuss HTTP/2 and WSGI.

Attached is the forwarded email from Robert with the kickoff details.

Historically, Django hasn't been deeply involved in process of developing
WSGI and related standards; this is an opportunity for us to change that
trend.

Yours,
Russ Magee %-)

-- Forwarded message --
From: Robert Collins 
Date: Sat, Sep 20, 2014 at 6:00 AM
Subject: HTTP/2 and WSGI
To: graham.dumple...@gmail.com, russ...@keith-magee.com, chr...@plope.com,
armin.ronac...@active-4.com, bchesn...@gmail.com, robe...@unbit.it
Cc: Nick Coghlan 


Hi gentle-folk, I'd like to draw your attention to
https://mail.python.org/pipermail/web-sig/2014-September/005244.html
wherein I am trying to get a working group of folk together to prep
WSGI for HTTP/2's new capabilities.

Nick pointed out that it would be a terrible thing to do this work and
then have major servers and frameworks hate on it because its not
going to work for them.

If you've limited time but can commit to e.g. reviewing drafts of the
PEP, that would be fine; OTOH if you can e.g put draft code together
in your respective projects, that would be better still :)

-Rob


--
Robert Collins 
Distinguished Technologist
HP Converged Cloud

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_LfW3gPqctw1AK7Px0hVHuUBZOO8LJLwkDSrJTSbh69Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should reverse() return a Unicode string?

[Jon Dufresne]

On Fri, Sep 19, 2014 at 5:13 AM, Tom Christie  wrote:
> One point of clarity is that we ought to return the same type for each of
> `reverse`, `request.path`, `request.get_full_path`, `request.path_info`, and
> the values in the `request.GET` dictionary. Given that, the answer is
> clearly "it should be a string".

>From my testing, these are all returning text strings except `reverse()`.

The pull request for the reverse() fix can be found here:


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b61tSxmGkpTnCgQ_51OZCkLzqHhKB1BwLy8jPoaXHRNAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: mod_security SQL injection rules and Django cookies

[Nikolai Prokoschenko]

Hello Carl, hello Florian,

thank you for your both replies, I feel confident that we'll sort it out 
now.

On Friday, September 19, 2014 5:56:08 PM UTC+2, Carl Meyer wrote:

I can't say for sure without checking, but I would be very surprised if 
> anything in Django's session code has a hard restriction to a length of 
> 12 characters. 
>

As far as I can see, a session ID is 32 characters per default and the 
default database backend model has a max_length of 40, so that's the only 
restriction there is. But I hope I can avoid subclassing a SessionStorage 
altogether.

Nikolai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c6cc7ef6-31ee-4fac-8890-e3d88c5d1389%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mod_security SQL injection rules and Django cookies

[Carl Meyer]

Hi Nikolai,

On 09/19/2014 05:50 AM, Nikolai Prokoschenko wrote:
> the people responsible for the Apache part of our Django application
> have recently introduced a policy for mandatory use of mod_security with
> OWASP ruleset. The SQL injection rule [1], has raised their attention,
> because it has found substrings like "XOr" and "0xa66e" in the
> "sessionid" and "csrftoken" cookies and has rejected the appropriate
> requests as a possible SQL injection attack (apparently, a known
> phenomenon in other environments as well [2]).
> 
> Based on that, we now have a request on the table to change hash key
> generation to something that doesn't produce any substrings looking like
> SQL (e.g. producing no more than two alphabetical symbols in a row or
> using hex strings). I consider this extremely risky, since the chance of
> session ID collisions increases noticeably (and on top of that, I don't
> want to go forking Django code). On the other hand, they consider
> disabling that rule risky since they think they'd be missing SQL
> injections; which shouldn't be a problem in my opinion, because we don't
> put raw cookie values into raw SQL statements (but they'd have to take
> my word for it) and everything else is ORM-managed.
> 
> I think I can argue against changing the hash generation routine and in
> favor of killing the mod_security rule. However, I'd like to have some
> additional information from Django developers to strenghten my case a bit.
> 
> 1. Has there been some security audit in the past which confirmed that
> session ID handling inside Django is not vulnerable to SQL injection
> attacks?

Not that I'm aware of.

> 2. Can I argue that Django's ORM is SQL injection safe (we are 99%
> ORM-based)?

There aren't known SQL-injection bugs in the ORM (unless of course you
use .raw() or .extra() or undocumented internal APIs and concatenate SQL
strings unsafely yourself), and any SQL-injection bug found would result
in a fix and security release.

> 3. In general, is my assumption correct that I'd be vastly reducing
> entropy if I implemented a session handler with different key
> generation? I can't really analyze [3] for collisions probability, esp.
> since it's not one of the usual suspects (MD5/SHA1/SHA256/etc.), but
> have a feeling that anything I'd produce will have a much higher percentage.

The docstring for `get_random_string` already gives you the equation for
the number of bits of entropy; it's not hard to calculate. It should be
easy enough to adjust that for different character sets and string
lengths and find something with equivalent entropy to the default.
Obviously, as Florian says, if you're decreasing the size of the
character set you'll need to increase the length to compensate.

I can't say for sure without checking, but I would be very surprised if
anything in Django's session code has a hard restriction to a length of
12 characters.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/541C51EF.8070407%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Should reverse() return a Unicode string?

[Tom Christie]

One point of clarity is that we ought to return the same type for each of 
`reverse`, `request.path`, `request.get_full_path`, `request.path_info`, 
and the values in the `request.GET` dictionary. Given that, the answer is 
clearly "it should be a string".

It's also a little unclear to me what type is currently expected from 
values in the `request.META` dictionary. I believe that the `HTTP_*` keys 
currently return byte objects, but it's not documented, or clear to me if 
that's consistently true.

On Thursday, 18 September 2014 22:11:39 UTC+1, Carl Meyer wrote:
>
> Hi Jon, 
>
> On 09/18/2014 02:01 PM, Jon Dufresne wrote: 
> > In my Django application, I'm making a strong attempt to always deal 
> > with Unicode strings at the application layer. Byte strings are only 
> > handled at the protocol layer -- sending data out on the "wire". If my 
> > application tests if an object is a string, I'll use isinstance(obj, 
> > unicode) (Python2). 
> > 
> > One gotcha that I noticed is that reverse() will always return a byte 
> > string. Tracing this through the code, I see this happens during the 
> > call to iri_to_uri(), as this function creates a string consisting 
> > only of ASCII characters, other characters are escaped. 
> > 
> > Now, reverse() is often used to grab a URL and handle it at the 
> > application layer. It is not reserved only for the protocol layer. An 
> > example would be presenting a URL inside a HTML template, (as an href 
> > or as text), mail, or JSON. 
> > 
> > In my opinion, reverse() should return a Unicode string, even if that 
> > string consists only of ASCII characters. It is not until the string 
> > hits the wire that it ought to be forced to bytes. 
> > 
> > To verify this, I have created a unit test that I placed in 
> > "urlpatterns_reverse.tests.URLPatternReverse" to demonstrate this is 
> > at the Django layer. 
> > 
> > def test_reverse_unicode(self): 
> > name, expected, args, kwargs = test_data[0] 
> > self.assertIsInstance( 
> > reverse(name, args=args, kwargs=kwargs), 
> > six.text_type) 
> > 
> > What do you think? If others agree, I can file a bug and create a pull 
> > request to fix this. 
>
> It makes sense to me that `reverse()` should return a text (unicode) 
> string. A URL may be "just bytes" on the network, but within the Django 
> context it is clearly text. 
>
> I'm a bit concerned about the backwards-compatibility implications, 
> particularly for Python 3 projects where `bytes` and `str` don't 
> silently interoperate. It would be really interesting to hear if anyone 
> on this list has a real-world Python 3 Django project handy and could 
> test the impact of this change. 
>
> Carl 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ec6d2143-2fe5-4f5f-8cbc-9e8236609a3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mod_security SQL injection rules and Django cookies

[Florian Apolloner]

Hi Nikolai,

On Friday, September 19, 2014 1:50:33 PM UTC+2, Nikolai Prokoschenko wrote:
>
> 1. Has there been some security audit in the past which confirmed that 
> session ID handling inside Django is not vulnerable to SQL injection 
> attacks?
>

Nothing public that I am aware of, no.

2. Can I argue that Django's ORM is SQL injection safe (we are 99% 
> ORM-based)?
>

Yes, at least there is no known problem in any backend (shipped with 
Django).
 

> 3. In general, is my assumption correct that I'd be vastly reducing 
> entropy if I implemented a session handler with different key generation? I 
> can't really analyze [3] for collisions probability, esp. since it's not 
> one of the usual suspects (MD5/SHA1/SHA256/etc.), but have a feeling that 
> anything I'd produce will have a much higher percentage.
>

Depending on how exactly you generate the key, you can be fine. So as an 
example: assuming you'd just have 0-9 and a-j and choose one item out of 
those every second step you'll have the same entropy as just choosing from 
0-9 all the time, but once you choose from 0-9 & a-j every time you have a 
higher space. That said, if you increase the length enough, you can make up 
for it (though you'd have to check if Django has problems with longer 
session ids).

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e7be322e-ad63-4c14-b63c-45b1d6284cc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

mod_security SQL injection rules and Django cookies

[Nikolai Prokoschenko]

Hello,

(disclaimer: it's a security question and I don't have any proper expertise 
in this area, so please bear with me)

the people responsible for the Apache part of our Django application have 
recently introduced a policy for mandatory use of mod_security with OWASP 
ruleset. The SQL injection rule [1], has raised their attention, because it 
has found substrings like "XOr" and "0xa66e" in the "sessionid" and 
"csrftoken" cookies and has rejected the appropriate requests as a possible 
SQL injection attack (apparently, a known phenomenon in other environments 
as well [2]).

Based on that, we now have a request on the table to change hash key 
generation to something that doesn't produce any substrings looking like 
SQL (e.g. producing no more than two alphabetical symbols in a row or using 
hex strings). I consider this extremely risky, since the chance of session 
ID collisions increases noticeably (and on top of that, I don't want to go 
forking Django code). On the other hand, they consider disabling that rule 
risky since they think they'd be missing SQL injections; which shouldn't be 
a problem in my opinion, because we don't put raw cookie values into raw 
SQL statements (but they'd have to take my word for it) and everything else 
is ORM-managed.

I think I can argue against changing the hash generation routine and in 
favor of killing the mod_security rule. However, I'd like to have some 
additional information from Django developers to strenghten my case a bit.

1. Has there been some security audit in the past which confirmed that 
session ID handling inside Django is not vulnerable to SQL injection 
attacks?

2. Can I argue that Django's ORM is SQL injection safe (we are 99% 
ORM-based)?

3. In general, is my assumption correct that I'd be vastly reducing entropy 
if I implemented a session handler with different key generation? I can't 
really analyze [3] for collisions probability, esp. since it's not one of 
the usual suspects (MD5/SHA1/SHA256/etc.), but have a feeling that anything 
I'd produce will have a much higher percentage.

If anyone had experienced a similar problem with mod_security, I'd be happy 
to hear how you resolved it or how you would have resolved it if you were 
in charge.

Thanks!

[1] 
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/base_rules/modsecurity_crs_41_sql_injection_attacks.conf

[2] 
http://stackoverflow.com/questions/21029081/detects-chained-sql-injection-attempts-1-2-in-phpsessid-cookie

[3] https://github.com/django/django/blob/master/django/utils/crypto.py#L54

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5e39d2e6-db01-4a64-b1c9-e449a3bb552b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading timezone naive data into your test database with USE_TZ = True

[Aymeric Augustin]

2014-09-18 23:29 GMT+02:00 Wim Feijen :

> Timezones confuse me, maybe Aymeric can answer this one if he has time?
>

I've bookmarked this thread to answer at some point but I have some
work-related matters to deal with first.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mWn1LLuBpxd9P4eNYgCCkv9nqbStVEp6B_U19wkvuLbNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.