Hot answers tagged

75

SQL injection. If you use Django's object-relational mapper (ORM) layer, you are basically protected from SQL injection. The only caveat is that you need to avoid manually forming SQL queries using string concatenation. For instance, do not use raw SQL queries (e.g., raw()). Similarly, do not use the extra() method/modifier to inject raw SQL. Do not ...


67

As joe says, there is no real security benefit to this. It is pure security theater. I'd like to highlight this from the documentation: If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value from a hidden CSRF token form input on the page instead of from the cookie. The purpose of the ...


20

Once an attacker already has access to the system it's already way too late. The main concern for not leaking the key is because it is often used as a seed for hashing and signing sessions. The idea is that your production SECRET_KEY needs to be completely different than your development or staging SECRET_KEY. You can actually randomly generate it every ...


12

First of all, thanks for the interesting question. I did not know about the details of CSRF before and had to look up the answer to your question myself, but I think I know the correct explanation for Django's behavior now. The Django developers are treating HTTP and HTTPS refers differently because users expect different things from insecure and secure web ...


10

That is correct. This is a false positive and the person providing this finding to you does not understand what they are doing unfortunately. Someone that understood the risks of mitm and csrf attacks would never provide this to you.


8

The class attribute could be used for redressing the UI to make untrusted elements and text appear to be authoritative text coming from the website itself. See the Google Browser Security Handbook for more information. Instead of writing your own, use an established HTML sanitiser such as Google Caja. These are hard to write because there are so many ways ...


8

Read it as: & == ; This bullet point just means that the Django framework for Python parses both an ampersand (&) and a semicolon (;) equally as valid separators of query parameters in a given URL. Consequently, the following URLs would be treated identically: https://example.com/foo/bar?x=y&name=peter&debug=1 https://example.com/foo/bar?x=...


7

I use Django a good deal and I did need to migrate 1.6 to 1.7 (although it was some 2-3 years ago). During that time the most important difference in terms of security was django.contrib.messages, which was not aware of HTTPS only cookies in Django 1.6. In other words, if you had something like: MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie....


5

A security advisory about the matter was posted on the Django blog: This issue does not affect Django directly, but will affect most users of Django. Any web server which is serving traffic over a CGI or CGI-like interface (including WSGI) should upgrade its version of Bash immediately.


5

One solution is to forbid access to the folder where the sensitive files are stored, so that it is not possible to access them directly. For example, place these files under http://siteis.com/secured_uploaded_files/ and place a .htaccess file there (for apache) to prevent access. You can also place the files outside the web server's document root. Step two ...


5

I think the main point of confusion here is that the Django docs are specifically talking about the CSRF use case for a cookie. In order to understand why the httpOnly flag adds no value in preventing CSRF, you need to understand both CSRF and how cookies work. CSRF is when a 3rd party triggers your user's browser to make a request to your server, and their ...


5

I'm the author of that article, as well as the somewhat popular tech talk I give about why JWTs suck and are stupid (all of which @joepie91 has eloquently written about much better than I ever could: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/). Given your application requirements (mobile app + JS front-end only app that both ...


4

BeatifulSoap is not designed as a Sanitizer for HTML but primarily designed for extracting data from the HTML like needed in screen scraping. That is don't expect it to deal correctly with malformed HTML which nevertheless gets executed by the browser. Apart from that a large part of your question is already answered in your previous one. And to cite myself ...


4

This is highly dependent on the application in question. So let's say for example you have a django web app that has many programmatic errors (not vulnerabilities). In this case you would be able to generate a lot of highly verbose error messages. If you were able to actually disclose the full contents of settings.py then you would be in big trouble. Your ...


4

Is HTTPS needed in this case? In every case that I can think of HTTPS is beneficial. The trivial case is if you don't have sessions, why would you need a secure connection if there are no sessions and everything is public? Having a secure connection actually helps your Google PageRank, and it also helps the user feel more secure by visiting your site If ...


4

Update bash, and this specific problem goes away. But if you want to know if you were vulnerable before this, there will be application specific paths to add to generic vulnerabilities (until bash is patched - then there may be new non-bash vulnerabilities discovered later with the same pattern). The specific problem is in allowing attacker controlled ...


3

$host will be set to $server_name if the client does not provide a Host header value in the request. You should use $http_host to access the pure Host header. See this document for details.


3

Designating the CSRF cookie as HttpOnly doesn’t offer any practical protection because CSRF is only to protect against cross-domain attacks. This can be stipulated in a much more general way, and in a simpler way by remove the technical aspect of "CSRF cookie". Designating a cookie as HttpOnly, by definition, only protects against access via document....


3

The only way CSRF prevention with double-submitting can work is by sending the nonce in a cookie. If you send it in the HTTP response body, it can in some cases be parsed out by a script sending a cross-domain request, (if you've allowed CORS for that page) which defeats the whole purpose of protecting against CSRF. The idea is that scripts on domain X can’t ...


3

The short answer, yes, you're always at risk. Should you be worried? Probably not, people like to be the center of attention and be charlatans, another time try to ask for technical details, how did he know that there were a compromise of his computer, what did he do to mitigate? If your operating system and running applications was updated, you had newly ...


3

This is trying to exploit a remote code execution vulnerability in ThinkPHP. So yes, someone is attempting to attack. Yes, although this specific one is specific for ThinkPHP, there are also regularly vulnerabilities for Django Yes, this is very common for web apps. This is not the only type of request to attack and a succesful attacker might change the log ...


2

In general there are valid URL schemes that are dangerous. Most obviously javascript:, which as a pseudo-URL refers not to a new location, but to a command to execute on the current page. Allowing a javascript: URL to be added to your page means you have a cross-site scripting problem. There are also other scripting aliases (vbscript:, mocha: et al), as ...


2

Bcrypt as stated in the Link is limited to 72 Characters. SHA256 may have an OUTPUT size of only 32 Bytes, It's Message input is ((2^64)-1)\8 or roughly 2305843009213693952 Bytes (assuming a char is 8 bits) To Bcrypt it's receiving a 32 Byte passphrase to encrypt, To SHA256 that could be a 400 Char data stream (IE password). So no, you're not losing ...


2

What's the content of your website? Is it anything anyone anywhere in the world could want to access without other people knowing about it (governments, marketers, snoops on the same wifi network)? Remember that what might be perfectly acceptable to view in your culture might not be acceptable elsewhere (like opinions about politics, sexuality or religion). ...


2

The issue was being caused by Nginx using my Django host as the default, so an "https://293.7.10.738/" request was being delegated to it. The solution was to add a default server. The default is used when no other server block's server_name doesn't match the request. It is chosen by Nginx to be: A server listening on the port (and address, if specified) ...


2

Not every framework upgrade is because of security, but if a version is no longer supported, this also impies there will be no bug/hot-fixes. That should be an important reason to upgrade regardless of the 'better' features in newer releases. Update As a counter argument, one could say the increase in functionality enlarges the attack surface, or introduce ...


2

CVE-2016-9013 and CVE-2015-5145 make the Django environment you're running susceptible to a denial of service attack and to information compromise; so poses a formidable information security risk. With Django 1.6.11 not receiving any security updates anymore there is no way to mitigate these risks (and other risks not mentioned here).


2

Sounds like you're trying to implement something like single sign-on between two of your apps. In this case, you should be able to without any significant security issue. Instead of authenticating with login credentials, you could have App B authenticate with App A's session ID. Obviously give the ID the same protections you'd give login creds, i.e. only ...


2

Almost certainly not. It's quite common to see automated attacks from web scanners - IPv4 is a pretty small address space and quite easy to enumerate (IPv6, at least, makes them work a bit to find targets!) It's a low-cost, low-success, but potentially high-reward tactic if they stumble on a server with interesting data and a terrible (or default) password. ...


2

The httpOnly attribute can be omitted from the anti-CSRF cookie in Django because, as many other answers and even the question highlighted, javascript code running in victim browsers that loaded an unauthorized origin will not be able to read authenticated responses from the authorized origin, with or without the attribute, due to Same Origin Policy. (Let'...


Only top voted, non community-wiki answers of a minimum length are eligible