Re: Should the Django session-id be hashed?

[Aymeric Augustin]

On 22 Sep 2016, at 20:32, James Bennett  wrote:

> So personally I'd like to hear some more about why this is seen as necessary 
> before I'd endorse work to actually implement it.


The reason why I originally filed a security report is that session stores tend 
to have less focus on security than databases.

Of course this is a moot point when sessions are stored in the database, but I 
won’t start a debate about why Django still encourages this, this isn’t the 
point of this thread ;-)

For example Redis is well known for advertising that it has no security and 
should only be run within a secure network. (Defense in depth, anyone?) Still a 
bunch of companies provide Redis as a service, usually on random EC2 instances 
directly reachable from the Internet. The best ones require going through an 
SSL endpoint and providing a password, but an attacker can still talk directly 
to Redis, which is concerning given its stance on security.

In contrast, the authors of PostgreSQL have implemented an authentication and 
authorization framework. I’m not qualified to say if it’s robust, but at least 
it’s better than shrugging off security entirely.

-- 
Aymeric.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0A4424F9-DA7B-4BB7-B558-34D4B3893CC7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[James Bennett]

For what it's worth, I'm suspicious of threat models which begin with
"assume the DB has already been significantly compromised..." simply
because there's so much someone can do if they gain even read access that
it's not worth expending a ton of effort hardening Django against those
cases.

Similarly, "assume a SQL injection vulnerability already exists" doesn't do
much for me because for something that lives and dies by the DB, that's
very close to "assume some remote-root vuln already exists and has been
exploited".

So personally I'd like to hear some more about why this is seen as
necessary before I'd endorse work to actually implement it.

On Thu, Sep 22, 2016 at 5:00 AM, Rigel  wrote:

> On Thu, Sep 22, 2016 at 12:31 PM, Curtis Maloney 
> wrote:
> > They're just a random string, I don't see how turning them into another
> > random string will help?  Or do you mean to set the original string in
> the
> > cookie only, and hash them for the key, and hash them _every_ _time_ you
> > look up the session?
>
> I'm an attacker and I've found a way to read the session database
> table. I can now impersonate user Bob.
>
> If the session-ids were hashed, I would need still need to know's
> Bob's session-id. Django woudn't store it anywhere on the database.
>
> Rigel.
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAD9P0Jr8uKogoeUz%3Dx1CHpC0hKQ4qyt5DVQo7vx-
> rZka7pYVyQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-NetD5GcA%2BjTkw0HGA0Hf8UfV4MDGRMpbSF5QT4t8aUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding aggregates to ModelAdmin.list_display

[Andrew Mosson]

We have an implementation of both annotations in *list_display* and adding 
an aggregates for the entire list (which we call *list_summary* and what 
you are calling here *list_aggregates*) and there are a bunch of subtleties 
in the interaction due to Admin's built in support for pagination and 
filtering

To demonstrate, let's use a simplified use case
assume models such as Author -< Book >- Genre (Book has FKs to both Author 
and Genre)

and and admin such as (as suggested in Stack Overflow post that Tim 
referenced (​already possible to some extent  

)

class AuthorAdmin(admin.ModelAdmin):
list_display = ('author_name', 'book_count', 'book_sum_price')
list_filters = ('book__genre__name', )
list_summary = (('Total Books', Sum('book_count'), ),
('Total Book Price', Sum('book_sum_price'), ))

def get_queryset(self, request):
return super(BookAdmin, self).get_queryset(request).annotate(
books_count=Count('books__name'),
books_sum_price=Sum('books__price'))

With regards to *list_summary* (or *list_aggregates* in the PR) our 
implementation summarizes the entire QuerySet not just a single page (my 
quick read of the patch seems to indicate that list_aggregates only 
aggregates a single page of the qs).  From my perspective summarizing a 
single page doesn't provide as much value summarizing the entire QS.  If 
one agrees  with that then feature will would have to support a user 
friendly name for the field (implemented here as a tuple - as suggested by 
Jim).  Additionally, if the feature summarizes the entire qs then the 
output should likely go above the table rather than as summary below (if it 
were below and the results were paginated, it would likely confuse the 
users)

With regards to extending list_display to support annotations there are 
subtle interactions between admin, annotated query sets and filters.

The qs that Django executes when the user has a filter looks like

Author.objects.annotate(...).filter(...)

In the code shown above this will produce the correct result set, but 
because annotate and filter aren't commutative 
,
 
the generated SQL ends up joining the Books table twice.  Additionally, 
there are probably some cases where complex filters will give unexpected 
results.  

Give that the user really wants

Author.objects.filter(...).annotate(...)

we ended up adding a modelAdmin.get_annotations(...) method and subclassing 
ChangeList to implement this feature.  

One additional note is that annotations require implementing a method on 
the modelAdmin class for each annotations which seems very boilerplate-ish. 
We have extended *list_display* to automatically handle the boilerplate as 
well.  

Since we use this extensively these features in our applications, we would 
be excited to see them implemented as part of admin.  We'd be happy to 
contribute here and if this seems like its worth pursuing I'll ask our team 
to look into refactoring the work we've done so that it could live in core 
rather than as sub-classes.

On Wednesday, September 21, 2016 at 6:17:27 PM UTC-7, Josh Smeaton wrote:
>
> I think I'm OK with `list_aggregates` because it implies a terminal 
> queryset method which really restricts the members used to create that 
> aggregation (the GROUP BY). Adding aggregates to existing list_display 
> would require something *else* to refine the group by using `values()`.
>
> If list_aggregates is a useful feature, then this sounds like an 
> appropriate way to implement that. Regular annotations could be added and 
> processed within list_display, provided list_display was modified to accept 
> expressions (either aggregates or regular annotations) in tuple form for 
> alias support.
>
> list_aggregates -> queryset.aggregate()
> list_display -> queryset.annotate(annotations).values()
>
> Does that make sense?
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/845eeb78-cebe-44cf-9ba7-a36c69522149%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Alasdair Nicol]

On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote:
>
> Another part I see is that the high coupling between Django and the URL 
> resolvers (as mentioned in 
> http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) 
> should probably be cleaned up, if it is desired to someday support 
> alternative URL resolvers. I'm willing to provide a patch for the checking 
> part, but I'm not sure if it would be accepted. Do I need to open a ticket 
> for that?
>
> I wrote the initial url checks code. The current tight coupling is the way 
the code turned out, it wasn't a deliberate design choice on my part. I 
read your blog post, and changing the code as you suggest so that the 
resolver can check itself sounds good to me. Yes, please open up a ticket 
to go with your patch.

Cheers,
Alasdair

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a6be9d8e-c297-44b9-8ead-8e215f696c7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

I'll try and update my library over the next couple of days to also support 
regex fragments and converters supporting parameters.

Another part I see is that the high coupling between Django and the URL 
resolvers (as mentioned in 
http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) should 
probably be cleaned up, if it is desired to someday support alternative URL 
resolvers. I'm willing to provide a patch for the checking part, but I'm 
not sure if it would be accepted. Do I need to open a ticket for that?

Kind regards,
Sjoerd Job

On Thursday, September 22, 2016 at 2:09:53 PM UTC+2, Tom Christie wrote:
>
> Wanted to add my support for this.
> Personally I'd be totally in favour of considering something along these 
> lines for core, once there's a fully proven design.
>
> The capture syntax is:
>
> * Far simpler.
> * Meets pretty much every single real-world case I ever see.
> * Gives us type coercion.
> * Also able to support regex fragments if needed. Eg see 
> http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing
>
> Given that we could continue to keep the existing style around as well, 
> this is an area where I'd be happy to see Django take a step forward.
>
> Sticking with the path->existing regex mapping implementation sounds like 
> the best tack, at least initially, rather than getting bogged down in API 
> discussions around how we'd tackle a routing API if we wanted to support 
> non-path routing.
>
> Cheers,
>
>   Tom
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7250a6ba-eb3f-4549-95a4-933367117a5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Tim Graham]

Sure, go ahead.

On Thursday, September 22, 2016 at 9:31:35 AM UTC-4, Violet Gibson wrote:
>
> Thanks for ticket link. 
>
> Would you mind if I assigned it to myself? I have a few ideas on how 
> it could be put together, and I'd like to work on it tonight and 
> submit a proposal. 
>
> Rigel. 
>
> On Thu, Sep 22, 2016 at 2:23 PM, Tim Graham  > wrote: 
> > The idea of adding an option to store the session ID hash rather than 
> the ID 
> > itself was discussed a few years ago on the core team mailing list (see 
> the 
> > "Authentication best practices" thread and "Don't store session IDs in 
> the 
> > clear" in the security issue tracker). Maybe we can reproduce some of 
> that 
> > thread here if it helps. The conclusion was to create this ticket: 
> > https://code.djangoproject.com/ticket/21076 
> > 
> > On Thursday, September 22, 2016 at 9:01:56 AM UTC-4, Erik Cederstrand 
> wrote: 
> >> 
> >> 
> >> > Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor : 
> >> > 
> >> > If Django were a different framework, I'd probably think this was a 
> >> > reasonable idea. However, Django's ORM is _incredibly_ good at 
> deterring SQL 
> >> > injection. In many many years of using and reviewing Django 
> applications, 
> >> > SQL injection is vanishingly rare in my experience; therefore I think 
> this 
> >> > adds complexity for limited gain. Another relevant factor is that 
> this is 
> >> > only applicable to the database sessions backend. 
> >> 
> >> The attacker would only need to read access for this to work, not write 
> >> access. That could possibly be achieved that even without SQL 
> injection. If 
> >> the attacker can just put another person's session ID in her cookie, 
> then 
> >> session IDs are basically passwords. Passwords should not be stored 
> >> clear-text. The only difference is that session IDs are more 
> short-lived 
> >> than passwords. 
> >> 
> >> It's the same issue with API key authentication for REST APIs. Not many 
> >> people remember to hash the keys before storing them in the DB. 
> >> 
> >> If the attacker gains write access to the DB, then you're doomed 
> anyway, 
> >> hashes or not. The attacker just makes up her own session ID, hashes it 
> and 
> >> writes it to the database. Or makes up her own password and writes it 
> to the 
> >> Users table. 
> >> 
> >> Erik 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/95f5f099-322f-4e25-ada0-0396af4dda5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Rigel]

Thanks for ticket link.

Would you mind if I assigned it to myself? I have a few ideas on how
it could be put together, and I'd like to work on it tonight and
submit a proposal.

Rigel.

On Thu, Sep 22, 2016 at 2:23 PM, Tim Graham  wrote:
> The idea of adding an option to store the session ID hash rather than the ID
> itself was discussed a few years ago on the core team mailing list (see the
> "Authentication best practices" thread and "Don't store session IDs in the
> clear" in the security issue tracker). Maybe we can reproduce some of that
> thread here if it helps. The conclusion was to create this ticket:
> https://code.djangoproject.com/ticket/21076
>
> On Thursday, September 22, 2016 at 9:01:56 AM UTC-4, Erik Cederstrand wrote:
>>
>>
>> > Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor :
>> >
>> > If Django were a different framework, I'd probably think this was a
>> > reasonable idea. However, Django's ORM is _incredibly_ good at deterring 
>> > SQL
>> > injection. In many many years of using and reviewing Django applications,
>> > SQL injection is vanishingly rare in my experience; therefore I think this
>> > adds complexity for limited gain. Another relevant factor is that this is
>> > only applicable to the database sessions backend.
>>
>> The attacker would only need to read access for this to work, not write
>> access. That could possibly be achieved that even without SQL injection. If
>> the attacker can just put another person's session ID in her cookie, then
>> session IDs are basically passwords. Passwords should not be stored
>> clear-text. The only difference is that session IDs are more short-lived
>> than passwords.
>>
>> It's the same issue with API key authentication for REST APIs. Not many
>> people remember to hash the keys before storing them in the DB.
>>
>> If the attacker gains write access to the DB, then you're doomed anyway,
>> hashes or not. The attacker just makes up her own session ID, hashes it and
>> writes it to the database. Or makes up her own password and writes it to the
>> Users table.
>>
>> Erik
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD9P0JoLaJvOQYAGOzW3wZBNJQowmaWHpo1MfEXiqYbfXzFLOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Tim Graham]

The idea of adding an option to store the session ID hash rather than the 
ID itself was discussed a few years ago on the core team mailing list (see 
the "Authentication best practices" thread and "Don't store session IDs in 
the clear" in the security issue tracker). Maybe we can reproduce some of 
that thread here if it helps. The conclusion was to create this 
ticket: https://code.djangoproject.com/ticket/21076

On Thursday, September 22, 2016 at 9:01:56 AM UTC-4, Erik Cederstrand wrote:
>
>
> > Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor  >: 
> > 
> > If Django were a different framework, I'd probably think this was a 
> reasonable idea. However, Django's ORM is _incredibly_ good at deterring 
> SQL injection. In many many years of using and reviewing Django 
> applications, SQL injection is vanishingly rare in my experience; therefore 
> I think this adds complexity for limited gain. Another relevant factor is 
> that this is only applicable to the database sessions backend. 
>
> The attacker would only need to read access for this to work, not write 
> access. That could possibly be achieved that even without SQL injection. If 
> the attacker can just put another person's session ID in her cookie, then 
> session IDs are basically passwords. Passwords should not be stored 
> clear-text. The only difference is that session IDs are more short-lived 
> than passwords. 
>
> It's the same issue with API key authentication for REST APIs. Not many 
> people remember to hash the keys before storing them in the DB. 
>
> If the attacker gains write access to the DB, then you're doomed anyway, 
> hashes or not. The attacker just makes up her own session ID, hashes it and 
> writes it to the database. Or makes up her own password and writes it to 
> the Users table. 
>
> Erik

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Erik Cederstrand]

> Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor :
> 
> If Django were a different framework, I'd probably think this was a 
> reasonable idea. However, Django's ORM is _incredibly_ good at deterring SQL 
> injection. In many many years of using and reviewing Django applications, SQL 
> injection is vanishingly rare in my experience; therefore I think this adds 
> complexity for limited gain. Another relevant factor is that this is only 
> applicable to the database sessions backend.

The attacker would only need to read access for this to work, not write access. 
That could possibly be achieved that even without SQL injection. If the 
attacker can just put another person's session ID in her cookie, then session 
IDs are basically passwords. Passwords should not be stored clear-text. The 
only difference is that session IDs are more short-lived than passwords.

It's the same issue with API key authentication for REST APIs. Not many people 
remember to hash the keys before storing them in the DB.

If the attacker gains write access to the DB, then you're doomed anyway, hashes 
or not. The attacker just makes up her own session ID, hashes it and writes it 
to the database. Or makes up her own password and writes it to the Users table.

Erik

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54777EE1-707B-4794-9854-394C5892587B%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Tom Christie]

Wanted to add my support for this.
Personally I'd be totally in favour of considering something along these 
lines for core, once there's a fully proven design.

The capture syntax is:

* Far simpler.
* Meets pretty much every single real-world case I ever see.
* Gives us type coercion.
* Also able to support regex fragments if needed. Eg see 
http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing

Given that we could continue to keep the existing style around as well, 
this is an area where I'd be happy to see Django take a step forward.

Sticking with the path->existing regex mapping implementation sounds like 
the best tack, at least initially, rather than getting bogged down in API 
discussions around how we'd tackle a routing API if we wanted to support 
non-path routing.

Cheers,

  Tom

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9a0ee2a3-37bc-4b4d-83e3-a2a1b6cf34e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Rigel]

On Thu, Sep 22, 2016 at 12:31 PM, Curtis Maloney  wrote:
> They're just a random string, I don't see how turning them into another
> random string will help?  Or do you mean to set the original string in the
> cookie only, and hash them for the key, and hash them _every_ _time_ you
> look up the session?

I'm an attacker and I've found a way to read the session database
table. I can now impersonate user Bob.

If the session-ids were hashed, I would need still need to know's
Bob's session-id. Django woudn't store it anywhere on the database.

Rigel.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD9P0Jr8uKogoeUz%3Dx1CHpC0hKQ4qyt5DVQo7vx-rZka7pYVyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Anthony King]

I have noticed that session id's are included in Django debug emails, with
no clear way to filter them out. I'm unsure of the behaviour with 1.9+, but
this is what I've experienced with 1.8.

The way around that issue though is to sign the cookie, so that people
can't just drop the session-id in.

On 22 September 2016 at 12:33, Florian Apolloner 
wrote:

>
>
> On Thursday, September 22, 2016 at 1:26:19 PM UTC+2, Violet Gibson wrote:
>>
>> Unless I'm missing something, these ids could be
>> vulnerable to SQL injection attacks, if any are discovered or if
>> developers misuse features like extra().
>
>
> Same is true for literally any field a user can write into.
>
>
>> What is your opinion on this matter?
>>
>
> Not worth it imo,
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/3c8e5034-b0ed-4dbc-b60c-
> a2f9b280926e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALs0z1Y3QmWivi72ym0pYf5-fhBDVdD7zQGN5oJk8BVNCPdWpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Alex Gaynor]

If Django were a different framework, I'd probably think this was a
reasonable idea. However, Django's ORM is _incredibly_ good at deterring
SQL injection. In many many years of using and reviewing Django
applications, SQL injection is vanishingly rare in my experience; therefore
I think this adds complexity for limited gain. Another relevant factor is
that this is only applicable to the database sessions backend.

Alex

On Thu, Sep 22, 2016 at 7:33 AM, Florian Apolloner 
wrote:

>
>
> On Thursday, September 22, 2016 at 1:26:19 PM UTC+2, Violet Gibson wrote:
>>
>> Unless I'm missing something, these ids could be
>> vulnerable to SQL injection attacks, if any are discovered or if
>> developers misuse features like extra().
>
>
> Same is true for literally any field a user can write into.
>
>
>> What is your opinion on this matter?
>>
>
> Not worth it imo,
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/3c8e5034-b0ed-4dbc-b60c-
> a2f9b280926e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFRnB2V0fcmfR1Z7Actbs4%2Bxh_pwzooq6uEes%3Ds6K_L%3DUYMehg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Florian Apolloner]

On Thursday, September 22, 2016 at 1:26:19 PM UTC+2, Violet Gibson wrote:
>
> Unless I'm missing something, these ids could be 
> vulnerable to SQL injection attacks, if any are discovered or if 
> developers misuse features like extra().


Same is true for literally any field a user can write into.
 

> What is your opinion on this matter?
>

Not worth it imo, 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c8e5034-b0ed-4dbc-b60c-a2f9b280926e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Curtis Maloney]

On 22/09/16 18:52, Rigel wrote:

Hello!

The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra().


Firstly, extra() is on is way out... being replaced by expressions, 
transforms, and so on...


That said, yes, extra() does potentially open you to SQL attacks, but 
only if you use it incorrectly.  If used as documented -- same goes for 
raw() -- you should remain immune to SQL injection.


The only time you're likely to become vulnerable to SQLi is when you do 
something as stupid as putting values into SQL commands yourself.



This vulnerability could be
mitigated if the session-ids were hashed with a secure cryptographic
hash function, like SHA-256, before storing them or querying for them
in the database.


They're just a random string, I don't see how turning them into another 
random string will help?  Or do you mean to set the original string in 
the cookie only, and hash them for the key, and hash them _every_ _time_ 
you look up the session?



This concern has recently been raised for Joomla! on the Full
Disclosure mailing list:
http://seclists.org/fulldisclosure/2016/Sep/50

What is your opinion on this matter? It could be fairly trivial to
implement, with the only side effect of being computationally
expensive. Still, security is more desirable than efficiency or
performance.


You are right there, security is more important.

However, it's a small overhead for everyone... for a small win for 
almost nobody.


Until you can demonstrate how there's any SQLi vulnerability, I'm -1 on 
this.


--
Curtis

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/16ef8ea5-cc5c-ad81-bdf8-f2d6f438bb61%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Should the Django session-id be hashed?

[Rigel]

Hello!

The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra(). This vulnerability could be
mitigated if the session-ids were hashed with a secure cryptographic
hash function, like SHA-256, before storing them or querying for them
in the database.

This concern has recently been raised for Joomla! on the Full
Disclosure mailing list:
http://seclists.org/fulldisclosure/2016/Sep/50

What is your opinion on this matter? It could be fairly trivial to
implement, with the only side effect of being computationally
expensive. Still, security is more desirable than efficiency or
performance.

Rigel.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD9P0Jr-pYSM%3DJkwiWoNg-BbfFbCxYW5ucbPy_dwssbiXS1d3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.