Re: Adding a security concerned feature
Hi All, I think at minimum we should change the default admin url for new projects, as that's very easy to do, and it does provide a lot of value for new projects. This helps Django to be secure by default. I use the default /admin/ url for my projects and bots are regurarly trying different password combinitations. In addition, security scanners are now starting to warn if you have an /admin/ url visible on your website. It would be a ton of work for me to change it, but it would be trivial if this were a new project. I think adding the project name as a prefix would help a lot and be very easy to do. https://github.com/django/django/compare/master...collinanderson:patch-14 (and then the docs would need to be updated too.) Thanks, Collin On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com wrote: > A security model doesn’t necessarily have to be any one thing that’s 100% > secure. It can be a combination of things which include “actual” security > features as well as plain ol’ obscurity. > > If I have to register the admin urls on a project, I make sure to setup > django-honeypot and move the admin site to something non-standard. > > Any one thing may not be doing much on it’s own. But the combination, if > messy enough to make someone give up, will give you a better overall > security situation. > > Just my 2¢. > > Onward, > Arvind > > On 19 Nov 2020, at 23:32, r...@whidbey.com wrote: > > FWIW, I agree with Tim and Carlton. There doesn't seem to me to be a > compelling argument for recommending developers to change the default > "/admin" url. Any security concerns would hopefully be addressed by actual > security safeguards rather than changing names to something non-standard. > > On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com > wrote: > >> On this topic, a ticket proposing to prepend the project name to the >> `admin/` URL in the default project template was opened. >> https://code.djangoproject.com/ticket/32209 >> >> Given that it's the exact discussion we're having here, I've paused that >> to see if there's a consensus for a change. >> >> Thanks. C. >> >> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote: >> >>> I've got this idea with the usage of json files that require some keys >>> which is authenticated for a single user which seems to excite me for fact >>> that if this was similar for admin/, then it'd give django a overhead >>> advantages for future use. >>> >>> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, >>> wrote: >>> I think I'd come down as -1 for a system check here... They're not costless, there's a tendency to want to add a new system check for every possible configuration choice, but, beyond implementing and maintaining, the danger is it leads to too much noise. If you get a system check warning, you shouldn't be tempted to ignore it. In general I think reserving the built-in checks slightly means they don't get devalued. (Folks are free, and encouraged, to implement, and share, their own checks to enforce project-level standards.) I think it's not sufficiently clear-cut that using `/admin/` is a bad idea to justify including a check. (On a personal note, I like to use `/admin/`, configure nginx to only serve the admin from the localhost, and then use an SSH tunnel to access it remotely, so I'd have to silence a system check here.) C. On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote: > > Hi, > > I wasn't convinced about changing the 'admin' path until recently. My > reasons to change the path of 'admin' are: > > -A bit less likely to be affected by bugs like > > https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form > > : at least the site wouldn't appear in automatic scans for > vulnerabilities (if checking Django versions based on the admin > template, etc.) . The bug/exploit might have been known before the fix > was implemented (and everyone updated) so I prefer to not be exposed > (or > less exposed) > > -At the moment in Django there is no rate-limiting login attempts "out > of the box" so I prefer to avoid the opportunity if possible > > -Partially out of my control: an 'admin' user might have used the same > password in another place and the password got leaked > > Other people might have other reasons. > > Cheers, > > On Nov/18/2020, Tim Graham wrote: > > I'm not convinced that a system check promoting security by > obscurity adds > > much value. The original poster wrote "sometimes it can be a > security > > concern." Maybe that's the case (how so?) but for most sites I would > say > > it's
Re: Adding a security concerned feature
That's security through obscurity that isn't too difficult to get past. It certainly raises the bar a bit, but like you said, the root problem is someone finding a login box and hammering away trying to guess usernames and passwords. I'm betting your 'standard' login box isn't difficult to find if your site has one. Once you have cracked an account, see if it gets you into /admin. I use django-axes. If you keep guessing passwords, your IP gets banned. Maybe a warning could be set that says "Your admin URL is at /admin, we recommend you change that"? I think the combination of blocking IPs and having a different admin URL would raise the bar quite a bit. -A On Wed, Nov 25, 2020 at 6:51 AM Collin Anderson wrote: > Hi All, > > I think at minimum we should change the default admin url for new > projects, as that's very easy to do, and it does provide a lot of value for > new projects. This helps Django to be secure by default. > > I use the default /admin/ url for my projects and bots are regurarly > trying different password combinitations. In addition, security scanners > are now starting to warn if you have an /admin/ url visible on your website. > > It would be a ton of work for me to change it, but it would be trivial if > this were a new project. > > I think adding the project name as a prefix would help a lot and be very > easy to do. > > https://github.com/django/django/compare/master...collinanderson:patch-14 > > (and then the docs would need to be updated too.) > > Thanks, > Collin > > > On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com > wrote: > >> A security model doesn’t necessarily have to be any one thing that’s 100% >> secure. It can be a combination of things which include “actual” security >> features as well as plain ol’ obscurity. >> >> If I have to register the admin urls on a project, I make sure to setup >> django-honeypot and move the admin site to something non-standard. >> >> Any one thing may not be doing much on it’s own. But the combination, if >> messy enough to make someone give up, will give you a better overall >> security situation. >> >> Just my 2¢. >> >> Onward, >> Arvind >> >> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote: >> >> FWIW, I agree with Tim and Carlton. There doesn't seem to me to be a >> compelling argument for recommending developers to change the default >> "/admin" url. Any security concerns would hopefully be addressed by actual >> security safeguards rather than changing names to something non-standard. >> >> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com >> wrote: >> >>> On this topic, a ticket proposing to prepend the project name to the >>> `admin/` URL in the default project template was opened. >>> https://code.djangoproject.com/ticket/32209 >>> >>> Given that it's the exact discussion we're having here, I've paused that >>> to see if there's a consensus for a change. >>> >>> Thanks. C. >>> >>> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote: >>> I've got this idea with the usage of json files that require some keys which is authenticated for a single user which seems to excite me for fact that if this was similar for admin/, then it'd give django a overhead advantages for future use. On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, wrote: > I think I'd come down as -1 for a system check here... > > They're not costless, there's a tendency to want to add a new system > check for every possible configuration choice, but, beyond implementing > and > maintaining, the danger is it leads to too much noise. > If you get a system check warning, you shouldn't be tempted to ignore > it. In general I think reserving the built-in checks slightly means they > don't get devalued. (Folks are free, and encouraged, to implement, and > share, their own checks to enforce project-level standards.) > > I think it's not sufficiently clear-cut that using `/admin/` is a bad > idea to justify including a check. > > (On a personal note, I like to use `/admin/`, configure nginx to only > serve the admin from the localhost, and then use an SSH tunnel to access > it > remotely, so I'd have to silence a system check here.) > > C. > > On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany > wrote: > >> >> Hi, >> >> I wasn't convinced about changing the 'admin' path until recently. My >> reasons to change the path of 'admin' are: >> >> -A bit less likely to be affected by bugs like >> >> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form >> : at least the site wouldn't appear in automatic scans for >> vulnerabilities (if checking Django versions based on the admin >> template, etc.) . The bug/exploit might have been known before the
Re: Request for Comment: settings growth configuring Email Backend.
Hi Carlton, On Tue, Nov 24, 2020 at 11:35 AM Carlton Gibson wrote: > Ticket 31885 Update SMTP Email Backend to use an SSLContext came in for which > there's a PR adding `EMAIL_SSL_CAFILE` &co settings to match the existing > EMAIL_USE_SSL &co settings. > > The PR looks fine in itself. > > I do wonder about the growth on the number of settings here. > It looks to my eye to get out of hand. I think the main problem is that the EMAIL_SSL_* settings map directly to smtplib parameters, and the old ones are deprecated in Python already since 3.6, but not yet in Django: https://docs.python.org/3.9/library/smtplib.html#smtplib.SMTP.starttls "Deprecated since version 3.6: keyfile and certfile are deprecated in favor of context. Please use ssl.SSLContext.load_cert_chain() instead, or let ssl.create_default_context() select the system’s trusted CA certificates for you." so EMAIL_SSL_CERTFILE and EMAIL_SSL_KEYFILE in Django should be marked as deprecated; people using it should be urged to use the new settings. If I'm not mistaken the old settings also do not do hostname verification, which is a security problem. So indeed, with adding the new settings there are a bit too much EMAIL_WHATEVER settings, the old ones should be marked deprecated and probably should have been marked as such some Django releases ago. -- Michiel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD0r11n_B8fgLic_W%2B4xg3kbxb-%3DxCTHh2sWr8jsLYHrK%3DdOA%40mail.gmail.com.
Model Generation for CSV, XLS Files
Hi everyone, I am Muskan and am very new to this community however not that new to django itself. Contributing to django is something I would really like to do, and I might also be participating in GSoc for the same. I have an vague idea of what I want to fix, because I myself have used django and just want to add things as a developer that I would've wanted as a user. So my question is understanding based around this idea of mine. *I want to know what functionality already exists that makes it easier to directly load a large data set into a django model from a CSV file (going with the simplest format or now).* When I had to do it as a user it took me quite a while and was a lot more complicated than I had expected, after being used to smooth transitions with load data. I could not find any better methods to do it, if there indeed exists no other methods, this is something I would like to work on So this is just to confirm if my research was thorough enough (very possibly wasn't). Thank you! I'm excited to begin helping out! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a3946181-cd91-4b83-b9d6-d8d8f786b6acn%40googlegroups.com.
Re: Model Generation for CSV, XLS Files
Hi Muskan, There isn’t anything that directly lets you load a CSV and generate models for it as far as I know (I may be wrong). But check out the Django documentation’s HOWTO on integrating with legacy databases - https://docs.djangoproject.com/en/3.1/howto/legacy-databases/. One possible solution for what you’re trying to do may be imagined as a flag for the ‘inspectdb’ command that lets you pass a CSV file? Just a thought. Good luck with GSOC. Onward, Arvind On 26 Nov 2020, at 0:30, Muskan Vaswan wrote: Hi everyone, I am Muskan and am very new to this community however not that new to django itself. Contributing to django is something I would really like to do, and I might also be participating in GSoc for the same. I have an vague idea of what I want to fix, because I myself have used django and just want to add things as a developer that I would've wanted as a user. So my question is understanding based around this idea of mine. *I want to know what functionality already exists that makes it easier to directly load a large data set into a django model from a CSV file (going with the simplest format or now).* When I had to do it as a user it took me quite a while and was a lot more complicated than I had expected, after being used to smooth transitions with load data. I could not find any better methods to do it, if there indeed exists no other methods, this is something I would like to work on So this is just to confirm if my research was thorough enough (very possibly wasn't). Thank you! I'm excited to begin helping out! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a3946181-cd91-4b83-b9d6-d8d8f786b6acn%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/158EA79E-91F4-4A65-83BD-73B5F81E94B8%40gmail.com.
