|
|
8 回复 | 直到 12 年前
|
1
6
首先,我会指出网络的不安全性,使他们能够被那些在思想上考虑安全的开发可能(不幸)是一个新概念的人所接受。例如,向他们演示如何拦截HTTP头并实现XSS攻击。你想让他们看到这些攻击的原因是,他们自己对自己的防御有了更好的了解。谈论安全性是很好的,但是如果不了解他们要阻止的攻击类型,他们将很难准确地“测试”他们的系统的安全性。一旦他们可以通过拦截消息、欺骗消息头等来测试安全性,那么他们至少知道他们试图实现的安全性是否有效。您可以自信地教他们您想要实现安全性的任何方法,知道他们是否弄错了,他们实际上会知道这一点,因为这会使您向他们展示的安全测试失败。 |
|
2
1
防御编程作为一个原型主题,涵盖了所有特定的攻击,因为大多数(如果不是全部)攻击都是由于缺乏足够的防御思考造成的。 把这个主题作为书的中心栏。当时对我很有帮助的是,我知道一些技术,不信任任何东西,而不仅仅是一个停止提示,比如“不允许在您的输入中使用SQL注释或特殊字符”。 另一件有趣的事情我很想早点学会,那就是如何实际测试它们。 |
|
|
3
1
我认为所有的漏洞都是基于程序员没有思考,或者是一时的判断失误,或者是他们没有想到的事情。我被指派“修复”应用程序中的一个大漏洞是,当登录的用户是管理员时,他们从身份验证方法返回了0(零)。由于变量最初是初始化为0的事实,如果发生任何问题(如数据库关闭),就会引发异常。变量永远不会被设置为正确的“安全代码”,然后用户就可以访问该站点了。这一过程中出现了绝对可怕的想法。所以,这让我想到了一个主要的安全概念;永远不要将表示“安全级别”的变量的初始值或任何类似的值设置为表示站点的完全上帝控制的值。更好的是,使用那些已经在大量生产环境中使用了很长一段时间的现有库。 |
|
|
4
1
我想看看ASP.NET安全与ASP经典安全的区别。 |
|
|
6
0
很高兴听到你将获得OWASP前十名。为什么不包括sans/cwe前25个编程错误的覆盖范围呢? |
|
|
7
0
如何确保您的安全方法在SQL Server中是可伸缩的。尤其是如何避免让SQL Server序列化来自多个用户的请求,因为它们都使用相同的ID进行连接… |
|
8
0
我总是试图在可能出错的事情上展示最坏的情况。例如,跨站点脚本注入如何能像黑盒攻击一样工作,甚至能在黑客自己无法访问的应用程序页面上工作,或者甚至SQL注入如何能像黑盒一样工作,以及 how a hacker can steal your sensitive business data ,即使您的网站使用普通的非特权登录帐户连接到数据库。 |
推荐文章