担心 XSS、CSRF、sql 注入、cookie 窃取是否足以覆盖网络安全？
在不安全的 WiFi 环境中，未受损计算机上的 Web 应用程序很容易受到 XSS、CRSF、sql 注入攻击和 cookie 窃取。
为了防止这些安全问题，有以下补救措施
- sql 注入：一个好的数据映射器（如 linq-to-sql）不存在 sql 注入的风险（我天真的相信这一点吗？）
- CSRF：每个表单帖子都经过验证<%:Html.AntiForgeryToken() %> （这是asp.net mvc环境中的令牌，存储在cookie中并在服务器上验证）
- XSS：每个允许发布html的表单都被转换，只允许bb代码，其余的都被编码。所有可能的保存操作都是通过 post 事件完成的，因此流氓 img 标签应该不会影响
- cookie 窃取：https
我现在不会受到基于网络的黑客攻击（正确实施时）吗？或者我在网络开发中遗漏了一些其他安全问题？（除了操作系统平台或其他软件中可能存在的漏洞）
Web applications on uncompromised computers are vulnerable to XSS,CRSF,sql injection attacks and cookie stealing in unsecure wifi environments.
To prevent those security issues there are the folowing remedies
- sql injection: a good datamapper(like linq-to-sql) does not have the risk of sql injection (am i naïeve to believe this?)
- CSRF: Every form-post is verified with the <%:Html.AntiForgeryToken() %> (this is a token in a asp.net mvc environment that is stored in a cookie and verified on the server)
- XSS: every form that is allowed to post html is converted, only bb code is allowed, the rest is encoded . All possible save actions are done with a post event so rogue img tags should have no effect
- cookie stealing: https
Am i now invulnerable to web-based hacking attempts(when implemented correctly)? Or am i missing some other security issues in web-development?(except for possible holes in the OS platform or other software)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
最简单的答案是“不，你并非刀枪不入——没有人是刀枪不入！”
这是一个好的开始，但您还可以做一些其他事情。您没有提到的主要问题是根据白名单验证不受信任的数据，这一点很重要，因为它涉及 SQLi 和 XSS 等多种漏洞利用。查看 OWASP 前 10 名对于 .NET 开发人员，第 1 部分：注入，特别是有关“所有输入必须根据可接受值范围的白名单进行验证”的部分。
接下来，您应该对连接到 SQL Server 的帐户应用最小权限原则。请参阅上一个链接中该名称下的标题。
鉴于您正在使用 ASP.NET，请确保请求验证保持打开状态，如果您绝对需要禁用它，只需在页面级别执行即可。有关此内容的更多信息，请参阅请求验证、DotNetNuke 和设计乌托邦 。
对于输出编码，最主要的是确保您针对正确的上下文进行编码。 HTML 编码！= JavaScript 编码！= CSS 编码。有关此内容的更多信息，请参阅 OWASP Top 10 .NET 开发人员第 2 部分：跨站脚本 (XSS)。
对于 cookie，将其设置为仅 HTTP，并且如果可能，仅允许安全地提供它们（如果您愿意仅通过 HTTPS 运行）。尝试将您的 web.config 通过 web.config 安全分析器，这将帮助您指出正确的方向。
另一种 CSRF 防御——尽管会影响可用性——是验证码。显然你想谨慎使用它，但如果你有任何想要保护的真正关键的功能，这会很快阻止它。更多内容请参见 OWASP Top 10 for . NET 开发人员第 5 部分：跨站点请求伪造 (CSRF)。
除此之外，听起来您还了解许多重要原则。它不会让你无懈可击，但这是一个好的开始。
The easy answer is "No you're not invulnerable - nobody is!"
This is a good start, but there are a few other things you could do. The main one you haven't mentioned is validation of untrusted data against a white-list and this is important as it spans multiple exploits such as both SQLi and XSS. Take a look at OWASP Top 10 for .NET developers part 1: Injection and in particular, the section about "All input must be validated against a whitelist of acceptable value ranges".
Next up, you should apply the principle of least privilege to the accounts connecting to your SQL Server. See the heading under this name in the previous link.
Given you're working with ASP.NET, make sure Request Validation remains on and if you absolutely, positively need to disable it, just do it at a page level. More on this in Request Validation, DotNetNuke and design utopia.
For your output encoding, the main thing is to ensure that you're encoding for the right context. HTML encoding != JavaScript encoding != CSS encoding. More on this in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).
For the cookies, make them HTTP only and if possible, only allow them to be served securely (if you're happy to only run over HTTPS). Try putting your web.config through the web.config security analyser which will help point you in the right direction.
Another CSRF defense - albeit one with a usability impact - is CAPTCHA. Obviously you want to use this sparingly but if you've got any really critical functions you want to protect, this puts a pretty swift stop to it. More in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF).
Other than that, it sounds like you're aware of many of the important principles. It won't make you invulnerable, but it's a good start.
因为，无论你有多优秀，每个人都会犯错误，答案是否定的。您几乎肯定忘记清理某些输入，或使用某些防伪令牌。如果您现在还没有，随着您的应用程序变得越来越大，您或其他开发人员将会这样做。
这是我们使用框架的原因之一 - 例如，MVC 将自动生成反 CSRF 令牌，而 LINQ-to-SQL（如您所提到的）将清理数据库的输入。因此，如果您尚未使用将反 XSS 和反 CSRF 措施设为默认值的框架，那么您应该立即开始。
当然，这些可以保护您免受这些特定威胁的侵害，但是永远不可能抵御所有威胁。例如，如果您的 SQL 连接密码不安全，那么有人可能会暴力破解您的数据库密码并获得访问权限。如果您不保持 .Net/SQL-Server/所有内容的版本保持最新，您可能会成为在线蠕虫的受害者（即使您这样做，仍然有可能成为零日漏洞）。
甚至还有一些软件无法解决的问题：脚本小子可能会对您的网站进行 DDOS。您的服务器公司可能会破产。一个阴暗的竞争对手可以简单地将树篱剪带到您的互联网线路上。你的仓库可能会被烧毁。开发人员可以将源代码出售给俄罗斯的一家公司。
再说一次，重点是，您不可能抵御所有的威胁 - 您只能抵御特定的威胁。
Because, no matter how good you are, everyone makes mistakes, the answer is no. You almost certainly forgot to sanitize some input, or use some anti-forgery token. If you haven't now, you or another developer will as your application grows larger.
This is one of the reason we use frameworks - MVC, for example, will automatically generate anti-CSRF tokens, while LINQ-to-SQL (as you mentioned) will sanitize input for the database. So, if you are not already using a framework which makes anti-XSS and anti-CSRF measures the default, you should begin now.
Of course, these will protect you against these specific threats, but it's never possible to be secure against all threats. For instance, if you have an insecure SQL-connection password, it's possible that someone will brute-force your DB password and gain access. If you don't keep your versions of .Net/SQL-Server/everything up to date, you could be the victim of online worm (and even if you do, it's still possible to be zero-dayed).
There are even problems you can't solve in software: A script kiddie could DDOS your site. Your server-company could go bankrupt. A shady competitor could simply take a hedge-clippers to your internet line. Your warehouse could burn down. A developer could sell the source-code to a company in Russia.
The point is, again, you can't ever be secure against everything - you can only be secure against specific threats.
这是 Web 攻击的权威指南。另外，我建议您对您的网络应用程序使用 Metasploit 。
This is the definitive guide to web attacks. Also, I would recommend you use Metasploit against your web app.
绝对是不够的！在开发网络应用程序时，您还必须牢记其他几个安全问题。
要获得概述，您可以使用 OWASP 十大
我认为这是在考虑网络安全时，请阅读一篇非常有趣的文章：开发人员在构建公共网站之前应该了解什么？
有一个关于安全性的部分，其中包含有关您在开发网络应用程序时面临的大多数威胁的良好链接。
考虑安全性时要记住的最重要的事情是：
永远不要相信用户输入！
[我回答这个“老”问题是因为我认为它始终是一个实际的主题。]
It definitely is not enough! There are several other security issues you have to keep in mind when developing a web-app.
To get an overview you can use the OWASP Top-Ten
I think this is an very interesting post to read when thinking about web-security: What should a developer know before building a public web site?
There is a section about security that contains good links for most of the threats you are facing when developing web-apps.
The most important thing to keep in mind when thinking about security is:
Never trust user input!
[I am answering to this "old" question because I think it is always an actual topic.]
关于您没有提到的内容：
您错过了 MVC 框架中的危险攻击：
过度发布攻击您还错过了最烦人的威胁：
拒绝服务code>您还应该对
文件上传（如果有的话...）以及更多...关于您提到的内容：
XSS真的非常非常浪费而且更烦人。编码有多种类型，包括Html 编码、Javascript 编码、CSS 编码、Html 属性编码、>Url Encoding, ...其中每一个都应该在正确的位置执行正确的内容 - 即仅对内容进行 Html 编码在所有情况下是不够的。
XSS 最烦人的是，在某些情况下你应该执行组合编码（即先JavascriptEncode，然后HtmlEncode...！！！）
看看下面的链接即可了解更多熟悉一个叫做 XSS 的噩梦......！！！
XSS 过滤器规避备忘单 - OWASP
About what you didn't mention:
You missed a dangerous attack in MVC frameworks:
Over Posting AttackYou also missed the most annoying threats:
Denial of ServiceYou also should pay enough attention to
file uploads(if any...) and many more...About what you mentioned:
XSSis really really really waster and more annoying to mitigate. There are several types of encoding includingHtml Encoding,Javascript Encoding,CSS Encoding,Html Attribute Encoding,Url Encoding, ...Each of them should be performed to the proper content, in the proper place - i.e. Just doing Html Encoding the content is not enough in all situations.
And the most annoying about XSS, is that there are some situations that you should perform Combinational Encoding(i.e. first JavascriptEncode and then HtmlEncode...!!!)
Take a look at the following link to become more familiar with a nightmare called XSS...!!!
XSS Filter Evasion Cheat Sheet - OWASP