网络安全测试
根据您的经验，您发现、处理过或遇到过哪些网站漏洞？您采取了哪些措施来缓解这些问题？
这可能包括 XSS（跨站点脚本）、SQL 注入攻击、普通的旧式 DDOS 或针对您网站客户的网络钓鱼尝试。就在昨天，我发现了 Firefox 工具的整个部分，用于审核网站及其潜在的各种漏洞。
希望扩展我在该领域的知识以获得职位，因此阅读或学习更多信息总是好的 - 也感谢可靠的链接！还有您发现的最糟糕的战争故事或您见过的最可怕的洞 - 从经验中学习有时是最好的方法！
In your experience, what have you found, worked on, or encountered in terms of site vulnerabilities? And what actions did you take to mitigate these issues?
This may include XSS (cross site scripting), SQL Injection attacks, plain old DDOS or phishing attempts on your site's customers. Only yesterday I came across an entire section of Firefox tools for auditing sites and their potential for various vulnerabilities.
Looking to expand my knowledge in this area for a role, so more information to read or learn is always good - solid links appreciated too! And war stories of the worst you've found or scariest hole you've seen - learning from experience is the best way sometimes!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我已经对数十个（数百个？）应用程序和站点进行了白盒和黑盒安全审查。
XSS 和 SQL 注入受到了很多关注，但知道我发现的最常见的安全缺陷是什么吗？将调试和测试功能留在生产代码中。无论是通过篡改 POST 参数 (isDebug=True) 还是通过蜘蛛抓取站点并查找剩余页面，这些都是我在安全方面看到的最严重的错误。如果您要包含测试/调试代码，请将其放在单独的代码分支中，或者至少在启动之前准备一份要删除的清单。
我见过的下一个最常见的漏洞就是通过从页面源获取 URL 来绕过安全机制的能力。技术名称是“强制导航”或“强制浏览”，这是任何可以阅读 HTML 的人都可以做到的事情，但令我惊讶的是各种易受攻击的应用程序。昨天查看了一个购票网站，我可以使用这种方法购买已售完的演出的门票。在以前的网站上，我能够完全跳过付款（许多 Paypal 网站通过 POST 参数将“购买完成”URL 传递给 Paypal - yoink！）。您需要某种后端状态或检查来确保完成、付款、可用性、准确性等。
坦白说，我通常使用 AppScan、BURP proxy、WebScarab、Fortify、FindBugs 或 YASCA 等工具（具体取决于预算和源代码可访问性）为我找到 XSS 和 SQL 注入攻击。我会自己尝试简单的东西，寻找明显的漏洞，但有太多已知的组合需要你自己尝试。我保留了一小部分脚本和测试用例，以应对更高级或最近发现的缺陷。
我将在 3 点停止，因为我真的可以继续一整天，我正在从你的问题中失去焦点，而且没有人愿意阅读文字墙。
为新晋和经验丰富的网络安全专家提供的一些资源：
（哎哟。我还不能正式发布链接。复制/粘贴。抱歉）
开放 Web 应用程序安全项目 (OWASP)
http://www.owasp.org/
网络安全测试指南
这本书是为审计人员、测试人员编写的，而不是为开发人员编写的。这对于奥莱利的书来说是很不寻常的。
websecuritytesting.com
Fortify 漏洞分类
www.fortify.com/vulncat/
常见弱点枚举（警告：广泛）
nvd.nist.gov/cwe.cfm
常见攻击模式枚举和分类（警告：更广泛）
capec.mitre.org/
Google 网络安全教程
（相当弱）
code.google.com/edu/security/index.html
I've done security review, white-box and black-box, for dozens (hundreds?) of applications and sites.
XSS and SQL injection get a lot of press, but know what I find the most common security flaw to be? Leaving debug and test functionality in production code. Either by tampering with POST parameters (isDebug=True) or via spidering a site and finding leftover pages, these are the worst mistakes I see regarding security. If you're including test/debug code, put it in a separate code branch, or at least prepare a checklist for removal prior to launch.
The next most common vulnerability I've seen is simply the ability to bypass security mechanisms by grabbing a URL from the page source. The technical name is 'Forceful Navigation' or 'Forced Browsing' This is something anyone who can read HTML can do, yet I'm surprised by the variety of applications vulnerable. Reviewing a ticket-purchasing site yesterday, I was able to buy tickets for sold-out shows using this method. On previous sites, I was able to skip paying altogether (many, many Paypal sites pass the "purchase complete" URL to paypal via POST parameters - yoink!). You need some sort of back-end statefulness or check to ensure completion, payment, availability, accuracy, etc.
To be frank, I usually let tools like AppScan, BURP proxy, WebScarab, Fortify, FindBugs, or YASCA (depending on budget and source code accessibility) find XSS and SQL injection attacks for me. I'll try the simple stuff on my own, look for obvious holes, but there's too many known combinations to try yourself. I keep a small collection of scripts and test cases for more advanced or recently discovered flaws.
I'm going to stop at 3, because I really could go on all day, I'm losing focus from your question, and nobody wants to read a wall of text.
Some resources for new and seasoned web security gurus:
(ARGH. I can't officially post links yet. Copy/paste. Sorry)
The Open Web Application Security Project (OWASP)
http://www.owasp.org/
Web Security Testing Cookbook
This book is written for auditors, testers, and less for developers. Which is pretty unusual for an O'Reilly book.
websecuritytesting.com
Vulnerability Categorization by Fortify
www.fortify.com/vulncat/
Common Weakness Enumeration (warning: extensive)
nvd.nist.gov/cwe.cfm
Common Attack Pattern Enumeration and Classification (warning: even more extensive)
capec.mitre.org/
Google's Web Security Tutorials
(rather weak)
code.google.com/edu/security/index.html
我加入了一个包含文档库的 Web 应用程序项目。它引用文档的方式类似于 http://example.com/getdocument?file=somefile。 pdf。当然，我只需要尝试 file=/etc/passwd，当然它有效。
解决方案：执行用户输入清理和/或在 URL 中请求的资源与实际文件系统资源之间使用某种程度的抽象。
这是 SQL 注入攻击的近亲。检查任何允许的请求，这些请求看起来可疑，似乎给了客户端太多的控制权。
I joined a web app project that included a document library. The way it referenced documents was something like http://example.com/getdocument?file=somefile.pdf. Of course I just had to try file=/etc/passwd, and of course it worked.
Solution: Perform user input sanitization and/or use some level of abstraction between resources requested in the URL and actual filesystem resources.
This is the cousin of SQL injection attacks. Examine any allowed request that suspiciously looks like it gives the client too much control.