The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

74

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 ...


53

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 ...


19

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 ...


10

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 ...


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=...


8

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.


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 ...


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 ...


4

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 ...


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

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

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

While the CSRF-Token is no secret on a page with a CSRF protected form (and could be stolen using XSS), you may have a XSS vulnerability in some page without a form. There you can only get the token from the cookie but not from a hidden field. In this case the security is improved by using a HttpOnly cookie. There is still a way to get the token by ...


2

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....


2

If you setup the web server with HTTP only the password will not be protected. The setting of LDAP_AUTH_USE_TLS=True only covers the protection of the connection between the server side part of your web application and the LDAP server and does not help in protecting the connection between browser and web server.


2

Is it possible to login with default credentials There is no default user, and the docs state: The username and email address for the new account can be supplied by using the --username and --email arguments on the command line. If either of those is not supplied, createsuperuser will prompt for it when running interactively. As such there is no default ...


1

MindSpark is a "Potentially Unwanted Program" flagged by several anti-malware/spyware tools. It is installed with many unwanted browser toolbars, and serves largely as a way of boosting advertising revenue and improving user tracking. I believe the cookies are injected across sessions including private/incognito browsing to allow websites to identify a user, ...


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