zoukankan      html  css  js  c++  java
  • Django remedy a security issue refer dos attack

    Today the Django team is issuing multiple releases -- Django 1.4.8, Django 1.5.4, and Django 1.6 beta 4 -- to remedy a security issue which was disclosed publicly by a third party earlier today. These releases are now available on PyPI and our download page.

    These releases address a denial-of-service attack against Django's authentication framework. All users of Django are encouraged to upgrade immediately.

    Release outside of normal security process

    Normally, our security process involves a one-week lead time for third parties on our security prenotification list. That process, however, relies on responsible disclosure practices which maintain confidentiality of a security issue until a coordinated public release date. To facilitate that, we ask that potential security issues always be reported via email to security@djangoproject.com, rather than through public channels such as Django's ticket tracker or the django-developers mailing list.

    This issue, unfortunately, could not be handled by our normal process, as it was first reported publicly on the django-developers mailing list. It has since been confirmed by the Django core team, and due to the already-public nature of the issue and the potential to impact live deployments of Django, we are instead issuing security releases immediately.

    Issue: denial-of-service via large passwords

    Django's authentication framework -- django.contrib.auth -- includes a default User model and backend which authenticates via username and password. The raw password is not stored in the database; instead, a hashed version of the password is stored, and the hash is computed each time a user attempts to log in. The hasher to use is configurable, via the PASSWORD_HASHERS setting.

    The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated "rounds" of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.

    Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large -- and guaranteed-to-fail -- passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

    This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.

    Although this is most effective against algorithms which are designed to be relatively "slow" to compute, such as PBKDF2 (which, again, is the default hasher in Django's authentication framework), it also is effective against other hashers, as the time to compute the hash generally grows with the size of the password.

    To remedy this, Django's authentication framework will now automatically fail authentication for any password exceeding 4096 bytes.

    Affected versions

    • Django master development branch
    • Django 1.6 (currently at beta status)
    • Django 1.5
    • Django 1.4

    At the time of this writing, efforts are being made to obtain a CVE for this issue. This post will be updated with the CVE once it has been obtained.

    Update: this issue was assigned CVE-2013-1443.

    Resolution

    Patches have been applied to Django's master development branch, and to the 1.6, 1.5 and 1.4 release branches, which resolve the issue described above. The patches may be obtained directly from the following changesets:

    The following new releases have been issued:

    General notes regarding security reporting

    As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list. If you think you may have found a security issue but aren't sure, we urge you to err on the side of caution, and report via email rather than public channels. Please see our security policies for further information.

    Posted by James Bennett on September 15, 2013

  • 相关阅读:
    [转载] 使用DBProxy读写分离
    [转载] 数据库索引类型及实现方式
    [转载] 分布式数据库ID生成系统
    将博客搬至CSDN
    ERROR:通过端口 1433 连接到主机 localhost 的 TCP/IP 连接失败。错误:“Connection refused: connect。请验证连接属性,并检查 SQL Server 的实例正在主机上运行,且在此端口接受 TCP/IP 连接,还要确保防火墙没有阻止到此端口的 TCP
    JAVA:对数据库的一系列操作代码
    JAVA与 SQL server2008进行连接
    怎么样将数据库的表在Java中界面中显示出来
    c#与c++交互的一些东西
    WPF实现摄像头镜像翻转
  • 原文地址:https://www.cnblogs.com/phoenix--/p/3325592.html
Copyright © 2011-2022 走看看