作为一个以应用程序安全顾问为生的人，有很多常见的问题让你通过一些东西来管理网站。但真正酷的是你可以买到价值一百万美元的袜子。

这是我的一个朋友的工作，但它的真实情况是，某个现在非常流行的在线图书(和其他所有东西)商店的商品价格被存储在HTML本身作为一个隐藏字段。在早期，这个漏洞困扰了许多在线商店，他们刚刚开始了解网络。几乎没有安全意识，谁会下载HTML，编辑隐藏字段，然后重新提交订单呢?

当然，我们把价格改为0，并订购了100万双袜子。你也可以改变价格为负，但这样做使他们的后端计费软件缓冲区溢出结束交易的一部分。

如果我可以选择另一个，那就是web应用程序中的路径规范化问题。能够执行foo.com?file=../../../ etc/passwd真是太棒了

一些朋友在大学里是同班同学。他们发现教授把所有的作业答案都贴出来了，甚至包括那些还没有交作业、还没有打分、甚至还没有布置的作业。教授只是把它们的链接或解决方案嵌入到课程网页中，并将它们注释在HTML注释中，直到作业被收集和评分。

去年，我发现我所在的公司用来处理支票/报表的网站充满了SQL注入漏洞。

不用说，他们很快就把洞补好了。

我不知道这是不是最糟糕的，因为我见过一些非常糟糕的，但是:

几年前，我工作的地方引进了一个叫做FOCUS的系统。不知道它还在不在。它非常适合做报告，我们开发并教了大约一千两个非It人员如何生成他们自己的报告。非常方便。他们可以做基本的报告，一些人可以做中等难度的工作，IT可以帮助处理较难的工作。

所有用于报告的数据都被定期复制到FOCUS自己格式的影子数据库中。对于更敏感的数据，我们设置安全选项，加密数据。一切都很好。

So, one day my boss calls me in, and we've lost the password to one of the sensitive databases. It's going to be hard to reproduce the data in this case, so he asks me to see if I can break the security. I had no experience as a hacker, so it took me about 5 or 6 hours to hand him the password. I started by creating some test files, and encrypting them with different passwords. I found that changing one character in the password would change two bytes in the encrypted file, specifically, the high nybble of one byte, and the low nybble of another byte. Hmmmm, says I. Sure enough, they stored the password somewhere in the first 80 bytes of the encrypted, but obfuscated the password by splitting the bytes into nybbles, and storing them in predictable places.

不久之后，我们就编写了一个REXX脚本，该脚本在VM/CMS系统下运行，可以告诉我们任何加密数据库的密码。

那是很久以前的事了——在90年代初，我相信他们已经解决了这个问题。嗯，非常确定。

在一所不知名的大学，他们所有的动作查询都是通过URL传递的，而不是通过表单发布的。

这个东西一直在工作，直到谷歌Bot出现，运行了他们所有的url并删除了他们的数据库。

我认为超级用户访问的空白用户名/密码字段是迄今为止最糟糕的。但我亲眼看到的是

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

太糟糕了，一个操作员就有这么大的不同。