在 Web.py 上进行身份验证 - 此代码对于生产来说会不安全吗？
我正在制作一个简单的网络应用程序，需要登录管理页面。我在 web.py 网站上遇到了这个咒语（http://webpy.org/cookbook/userauth ) ：
import hashlib
import web
def POST(self):
i = web.input()
authdb = sqlite3.connect('users.db')
pwdhash = hashlib.md5(i.password).hexdigest()
check = authdb.execute('select * from users where username=? and password=?', (i.username, pwdhash))
if check:
session.loggedin = True
session.username = i.username
raise web.seeother('/results')
else: return render.base("Those login details don't work.")
然而，该页面还给出了一个有点不祥的警告：“不要在真实站点上使用此代码 - 这仅用于说明。”。我想知道这是否存在任何重大漏洞，我对网络编程有些不熟悉，所以只是想确保使用此代码不会无意中使应用程序对微不足道的攻击向量开放？
非常感谢
I am making a simple web-app which requires login for the admin page. I came across this incantation on the web.py site (http://webpy.org/cookbook/userauth) :
import hashlib
import web
def POST(self):
i = web.input()
authdb = sqlite3.connect('users.db')
pwdhash = hashlib.md5(i.password).hexdigest()
check = authdb.execute('select * from users where username=? and password=?', (i.username, pwdhash))
if check:
session.loggedin = True
session.username = i.username
raise web.seeother('/results')
else: return render.base("Those login details don't work.")
However the page also gives a somewhat ominous warning: "Do not use this code on real site - this is only for illustration.". I was wondering if there are any major holes in this, I'm somewhat unfamiliar with web-programming so just wanted to make sure that using this code wont unwittingly make the app open to trivial attack vectors?
Many thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从用户名=？的用户中选择*和密码=？'，（i.username，pwdhash）
^ SQL注入，broseph。如果有人在搜索字段中输入“or 1=1”，由于 SELECT * from，他们将获得用户中的第一个结果。通常第一个条目是管理员凭据。
select * from users where username=? and password=?', (i.username, pwdhash)
^ SQL injection, broseph. If someone does 'or 1=1' into the search field, they'll get the first result in users because of the SELECT * from. Often the first entry is the admin credentials.
我看到的唯一明显的问题是密码是用简单的 MD5 哈希值存储的，没有加盐。从您的角度来看，这并不是什么大问题，但从用户的角度来看，这是一个重大的安全缺陷，因为有权访问数据库的人只需通过谷歌搜索他们的 MD5 哈希值就可以相当轻松地破解足够糟糕的密码。
The only glaringly obvious problem I see is that the password is stored with as simple MD5 hash with no salt. From your point of view, this isn't so much of an issue, but from the user's point of view it's a major security flaw since someone with access to the database can fairly easily crack sufficiently bad passwords by just googling their MD5 hashes.
我在这里能想到的唯一可能的问题是，是否可以以某种方式利用MD5 冲突< /a>，即两个不同的字符串可以生成相同的 MD5 哈希值 - 在这种情况下，有人可能会使用不正确的密码登录，但会生成相同的 MD5 哈希值。
更改为更好的哈希算法，例如 SHA-1（或 hashlib< 中提供的其他算法） /a>) 将解决这个潜在的安全问题。
据我所知，利用MD5冲突问题来获取访问权限是非常困难的。即便如此，它还是被破坏了，并引用了维基百科文章中的安全大师 Bruce Schneier 的话：
The only possible problem I can think of here, could be if it would somehow be possible to exploit MD5 collisions, i.e. that two different strings can generate the same MD5 hash - in that case someone could potentially log in with a password that is not correct, but generates the same MD5 hash.
Changing to a better hashing algorithm such as SHA-1 (or something else available in hashlib) would close this potential security problem.
As far as I know, it would be very difficult to exploit the MD5 collision problem to gain access. Even so, it is broken, and quoting security guru Bruce Schneier from the wikipedia article: