Since you used the word "Agile", I'm guessing it's a web app. I have a nice easy answer for you.
Go buy a copy of Burp Suite (it's the #1 Google result for "burp" --- a sure endorsement!); it'll cost you 99EU, or ~$180USD, or $98 Obama Dollars if you wait until November.
Burp works as a web proxy. You browse through your web app using Firefox or IE or whatever, and it collects all the hits you generate. These hits get fed to a feature called "Intruder", which is a web fuzzer. Intruder will figure out all the parameters you provide to each one of your query handlers. It will then try crazy values for each parameter, including SQL, filesystem, and HTML metacharacters. On a typical complex form post, this is going to generate about 1500 hits, which you'll look through to identify scary --- or, more importantly in an Agile context, new --- error responses.
Fuzzing every query handler in your web app at each release iteration is the #1 thing you can do to improve application security without instituting a formal "SDLC" and adding headcount. Beyond that, review your code for the major web app security hot spots:
Use only parameterized prepared SQL statements; don't ever simply concatenate strings and feed them to your database handle.
Filter all inputs to a white list of known good characters (alnum, basic punctuation), and, more importantly, output filter data from your query results to "neutralize" HTML metacharacters to HTML entities (quot, lt, gt, etc).
Use long random hard-to-guess identifiers anywhere you're currently using simple integer row IDs in query parameters, and make sure user X can't see user Y's data just by guessing those identifiers.
Test every query handler in your application to ensure that they function only when a valid, logged-on session cookie is presented.
Turn on the XSRF protection in your web stack, which will generate hidden form token parameters on all your rendered forms, to prevent attackers from creating malicious links that will submit forms for unsuspecting users.
Use bcrypt --- and nothing else --- to store hashed passwords.
Make sure you unit test as early as possible (e.g. the password should be encrypted before sending, the SSL tunnel is working, etc). This would prevent your programmers from accidentally making the program insecure.
Defense Programming
I personally call this the Paranoid Programming but Wikipedia is never wrong (sarcasm). Basically, you add tests to your functions that checks all the inputs:
is the user's cookies valid?
is he still currently logged in?
are the function's parameters protected against SQL injection? (even though you know that the input are generated by your own functions, you will test anyway)
Logging
Log everything like crazy. Its easier to remove logs then to add them. A user have logged in? Log it. A user found a 404? Log it. The admin edited/deleted a post? Log it. Someone was able to access a restricted page? Log it.
Don't be surprised if your log file reaches 15+ Mb during your development phase. During beta, you can decide which logs to remove. If you want, you can add a flag to decide when a certain event is logged.
I'm no expert on Agile development, but I would imagine that integrating some basic automated pen-test software into your build cycle would be a good start. I have seen several software packages out there that will do basic testing and are well suited for automation.
I'm not a security expert, but I think the most important fact you should be aware of, before testing security, is what you are trying to protect. Only if you know what you are trying to protect, you can do a proper analysis of your security measures and only then you can start testing those implemented measures.
Very abstract, I know. However, I think it should be the first step of every security audit.
发布评论
评论（4）
您的应用领域是什么？ 这取决于。
既然您使用了“敏捷”这个词，我猜它是一个网络应用程序。 我有一个简单的答案给你。
去购买一份 Burp Suite（这是“burp”的 Google 结果排名第一——绝对的认可！）； 如果你等到 11 月的话，它会花费你 99 欧元，或者大约 180 美元，或者 98 美元奥巴马美元。
Burp 用作网络代理。 您使用 Firefox 或 IE 或其他浏览器浏览您的网络应用程序，它会收集您生成的所有点击。 这些点击会被输入到一个名为“Intruder”的功能，这是一个网络模糊器。 Intruder 将找出您提供给每个查询处理程序的所有参数。 然后它会尝试每个参数的疯狂值，包括 SQL、文件系统和 HTML 元字符。 在典型的复杂表单帖子中，这将生成大约 1500 个点击，您将通过查看这些点击来识别可怕的 — 或者，更重要的是，在敏捷环境中，新的 — 错误响应。
在每次发布迭代时对 Web 应用程序中的每个查询处理程序进行模糊测试是提高应用程序安全性的第一件事，而无需建立正式的“SDLC”并增加人员数量。 除此之外，检查您的代码以了解主要的 Web 应用程序安全热点：
仅使用参数化准备好的 SQL 语句； 永远不要简单地连接字符串并将它们提供给数据库句柄。
将所有输入过滤到已知好字符（alnum、基本标点符号）的白名单中，更重要的是，从查询结果中输出过滤数据，以将 HTML 元字符“中和”为 HTML 实体（quot、lt、gt 等） ）。
测试应用程序中的每个查询处理程序，以确保它们仅在提供有效的已登录会话 cookie 时才起作用。
测试应用程序中的每个查询处理程序，以确保
在您的网络堆栈中启用 XSRF 保护，这将在您呈现的所有表单上生成隐藏的表单令牌参数，以防止攻击者创建向毫无戒心的用户提交表单的恶意链接。
使用 bcrypt --- 不使用其他 --- 来存储散列密码。
What's your application domain? It depends.
Since you used the word "Agile", I'm guessing it's a web app. I have a nice easy answer for you.
Go buy a copy of Burp Suite (it's the #1 Google result for "burp" --- a sure endorsement!); it'll cost you 99EU, or ~$180USD, or $98 Obama Dollars if you wait until November.
Burp works as a web proxy. You browse through your web app using Firefox or IE or whatever, and it collects all the hits you generate. These hits get fed to a feature called "Intruder", which is a web fuzzer. Intruder will figure out all the parameters you provide to each one of your query handlers. It will then try crazy values for each parameter, including SQL, filesystem, and HTML metacharacters. On a typical complex form post, this is going to generate about 1500 hits, which you'll look through to identify scary --- or, more importantly in an Agile context, new --- error responses.
Fuzzing every query handler in your web app at each release iteration is the #1 thing you can do to improve application security without instituting a formal "SDLC" and adding headcount. Beyond that, review your code for the major web app security hot spots:
Use only parameterized prepared SQL statements; don't ever simply concatenate strings and feed them to your database handle.
Filter all inputs to a white list of known good characters (alnum, basic punctuation), and, more importantly, output filter data from your query results to "neutralize" HTML metacharacters to HTML entities (quot, lt, gt, etc).
Use long random hard-to-guess identifiers anywhere you're currently using simple integer row IDs in query parameters, and make sure user X can't see user Y's data just by guessing those identifiers.
Test every query handler in your application to ensure that they function only when a valid, logged-on session cookie is presented.
Turn on the XSRF protection in your web stack, which will generate hidden form token parameters on all your rendered forms, to prevent attackers from creating malicious links that will submit forms for unsuspecting users.
Use bcrypt --- and nothing else --- to store hashed passwords.
单元测试，防御编程和大量日志
单元测试
确保尽早进行单元测试（例如，密码应在发送前加密，SSL 隧道正在工作等）。 这可以防止程序员意外地使程序变得不安全。
防御编程
我个人称之为偏执编程，但维基百科从来没有错（讽刺）。 基本上，您向函数添加测试来检查所有输入：
记录
疯狂地记录所有内容。 删除日志然后添加日志更容易。 用户已登录？ 记录下来。 用户发现了 404？ 记录下来。 管理员编辑/删除了帖子？ 记录下来。 有人能够访问受限制的页面吗？ 记录下来。
如果您的日志文件在开发阶段达到 15+ Mb，请不要感到惊讶。 在测试期间，您可以决定删除哪些日志。 如果需要，您可以添加一个标志来决定何时记录特定事件。
Unit testing, Defense Programming and lots of logs
Unit testing
Make sure you unit test as early as possible (e.g. the password should be encrypted before sending, the SSL tunnel is working, etc). This would prevent your programmers from accidentally making the program insecure.
Defense Programming
I personally call this the Paranoid Programming but Wikipedia is never wrong (sarcasm). Basically, you add tests to your functions that checks all the inputs:
Logging
Log everything like crazy. Its easier to remove logs then to add them. A user have logged in? Log it. A user found a 404? Log it. The admin edited/deleted a post? Log it. Someone was able to access a restricted page? Log it.
Don't be surprised if your log file reaches 15+ Mb during your development phase. During beta, you can decide which logs to remove. If you want, you can add a flag to decide when a certain event is logged.
我不是敏捷开发方面的专家，但我认为将一些基本的自动化渗透测试软件集成到您的构建周期中将是一个好的开始。 我见过几个可以进行基本测试并且非常适合自动化的软件包。
I'm no expert on Agile development, but I would imagine that integrating some basic automated pen-test software into your build cycle would be a good start. I have seen several software packages out there that will do basic testing and are well suited for automation.
我不是安全专家，但我认为在测试安全性之前，您应该了解的最重要的事实是您要保护的内容。 只有知道要保护的内容，才能对安全措施进行正确分析，然后才能开始测试这些已实施的措施。
我知道，非常抽象。 但是，我认为这应该是每次安全审核的第一步。
I'm not a security expert, but I think the most important fact you should be aware of, before testing security, is what you are trying to protect. Only if you know what you are trying to protect, you can do a proper analysis of your security measures and only then you can start testing those implemented measures.
Very abstract, I know. However, I think it should be the first step of every security audit.