我应该测试一个用于 SQL 注入的 Web 应用程序。我是这种类型的安全测试的新手,我想得到一些关于此事的提示。是否有任何最佳实践,或者我只是在 Internet 上搜索最常见的 SQL 注入并在我的应用程序上进行尝试?
我希望一些指导对像我这样的其他新手来说是有利可图的,所以请帮助我完成以下列表:
要测试的应用程序中的“地点”列表:
- 用户名
- 密码
- 电子邮件
- 搜索栏
- 文本字段
- 用户可用的任何其他字段
要执行的测试列表:
- ...?
谢谢!
我应该测试一个用于 SQL 注入的 Web 应用程序。我是这种类型的安全测试的新手,我想得到一些关于此事的提示。是否有任何最佳实践,或者我只是在 Internet 上搜索最常见的 SQL 注入并在我的应用程序上进行尝试?
我希望一些指导对像我这样的其他新手来说是有利可图的,所以请帮助我完成以下列表:
要测试的应用程序中的“地点”列表:
要执行的测试列表:
谢谢!
这种测试非常有趣,并且可以暴露其核心焦点之外的各种缺陷;确保您不能破坏数据。我不是专家,但我确实有一些建议,希望对您有所帮助。
有多种方法可以尝试将 SQL 查询和命令注入 Web 应用程序;文本输入字段是最明显的,但根据您网站的工作方式,您可能能够操纵 URL 来传输注入攻击。如果您可以上传到您的 Web 应用程序,请不要忘记尝试将文件名设置为注入攻击。
必须熟悉相关数据库;如果它不是非常复杂,请向设计师索要 ERD(实体关系图)。如果它非常复杂(大量的表、视图和索引),那么请在关键领域寻求一些指导。
我通常尝试的攻击类型包括尝试删除表、尝试删除或更改实体,或者尝试通过快速连续的复杂查询访问数据库以尝试使数据库服务器过载。您需要在您使用的环境(MySQL 与 MS SQL)中介绍 SQL 语法。
最后,我倾向于使用各种方法来超越文本框上的过滤器;在尝试了普通 SQL 语法之后,使用 HTML 或 UTF 编码而不是字符文字可能会发现大量错误。像这样的东西:
<alert"!xss!</<
与使用文字相反:
<alert>"xss"</alert>
这有时会欺骗应用程序服务器,将原本无害的字符转换为危险的字符串。
如前所述,这种测试通常会发现与您的数据库无关的错误。例如,我曾经上传了一个带有编码“drop table”查询的文件,该查询破坏了页面,因此无法显示我的上传历史记录。
希望这可以帮助。
从应用程序级别,您需要检查代码如何处理参数。是否对这些参数进行了任何验证(长度、数据类型检查)?
最佳实践:
替代方案我建议您查看代码的编写方式。
你可以检查一下
我认为这个问题更适合http://security.stackexchange.com。那里已经回答了以下与您的问题类似的问题:
我必须说,我喜欢 BrMcMullin 的回答。这是一个使用工具可以教给你很多东西的领域。有很多好的开源和免费的,但是,我对其中的大多数都不熟悉(公司为一些不错的漏洞管理软件买单)。您可以随时查看penTestIT 之类的网站以获取一些建议。就我个人而言,因为我可以使用它,所以我通常在进行其他一些测试时在后台进行自动化操作。因为它向您展示了它在做什么,所以很有帮助。
在此之后,我完全按照 BrMcMullin 所说的去做。在这方面,我打开的只是我的浏览器、提琴手和一些好听的音乐。
至于您的第二个问题,关于在哪里进行测试,太多人将自己限制在文本字段中。查看您的查询从何处获取信息。通常,还使用选择框和单选按钮,来自这些输入的数据不会像文本字段那样在任何地方进行检查。
我几乎可以保证,当你发现你是第一个 sql 注入 bug 之后,你会有很多新的想法来测试它,因为你会想继续前进。这很有趣,也是让您的创意源源不断的好方法。