我已经找到了几十篇关于个人安全主题的文章,但我无法理解大局以及它们在实践中如何融合在一起.
我需要看一个鸟瞰路线图.拿这个假设的例子：
A Simple Hypothetical “Comments” Section:
Sign up: create a password/username combo that is to be stored safely in a MySQL table.
Log in.
Leave a comment.
这个最基本的案例将遵循什么是“安全路线图”？
>我假设程序员不是服务器管理员,并且服务器管理员或多或少知道默认情况下如何正确安全地配置LAMP.
当然,如果有必要,程序员可以覆盖位于Web根目录中的自定义PHP.ini文件中的大多数PHP设置.
>使用MVC框架.
我使用CakePHP.该框架本身在很大程度上确保了基本健全和安全的编码实践.
B.收到的数据……
>在以编程方式操作数据之前,清理并验证$_GET,$_POST,$_COOKIE和$_REQUEST中包含的所有数据.
> sql注入
定义：代码注入技术,利用应用程序的数据库层中发生的安全漏洞.当用户输入被错误地过滤为嵌入在sql语句中的字符串文字转义字符或用户输入没有强类型并因此意外执行时,存在漏洞.
预防：使用MysqLi或PDO等库进行参数化查询.请参阅OWASP SQL Injection cheat sheet(不建议使用字符串转义函数,如MysqL_real_escape_string)
>跨站点脚本(XSS)
定义：Web应用程序中常见的安全漏洞,允许恶意Web用户将代码注入其他用户查看的Web页面.这种代码的示例包括客户端脚本(即,JavaScript).
预防：依赖于上下文的输出转义和编码.见OWASP XSS prevention cheat sheet.
C.浏览器请求……
>跨站点请求伪造(CSRF)
定义：网站的恶意利用类型,从而从网站信任的用户传输未经授权的命令.与利用用户对特定站点的信任的跨站点脚本(XSS)不同,CSRF利用站点在用户浏览器中的信任.
预防：通常在浏览器会话启动时生成唯一的“令牌”.在所有POST和GET请求中传递令牌.在POST / GET操作之后,检查会话中是否存在令牌,然后确认POST / GET发送的令牌与会话中存储的令牌相同. (像CakePHP这样的MVC框架使得在整个应用程序中统一实现相对容易.)
D.会议……
>终止会话时销毁会话数据
会话完成后(“注销”),销毁其数据,不要只清除cookie(恶意用户只能重新启动cookie并再次使用会话).通过将其分配给空数组来取消设置$_SESSION中的所有索引.
>将会话存储为Web根目录或数据库中的文件
在服务器上保存会话的默认路径可能被劫持 – 尤其是在共享托管环境中.
E.密码……
>强制选择强密码
>密码中需要数字,符号,大写和小写字母
>密码长度应为12到14个字符左右
>哈希和盐所有密码
不要使用sha1(),md5()或hash()来哈希密码.它们不是为此而设计的.您将需要使用像bcrypt或PBDFK2这样的函数.有some really good suggestions on this question.你的盐值应该是完全随机的,并存储在数据库中(这不是一个秘密).一个额外的秘密值(通常称为“胡椒”)可以存储在您的应用程序中,并在使用bcrypt之前预先设置密码,但目前尚不清楚它真正增加了多少安全性.
>禁用register_globals
预防：register_globals =关闭
>禁用魔法引号
预防：magic_quotes_gpc =关闭
>禁用错误报告
预防：display_errors =关闭
>启用错误日志记录并将日志文件保存到Web根目录以上的目录中
预防：
log_errors = On; ignore_repeated_errors = On; html_errors = Off; error_log = /path/above/webroot/logs/PHP_error_log
>将会话数据存储在Web根目录上的目录中
预防：session.save_path = / path / above / webroot / sessions
G.在位于Web根目录的.htaccess文件中…
>在站点范围内禁用目录列表
预防：选项 – 索引
H.有价值/敏感文件……
>通过在Web根目录上存储此类文件来防止未经授权的访问/下载
这包括站点管理/仅限成员的部分和站点/数据库配置文件！
>使用中间脚本以内联方式或作为附件提供文件
>保持脚本(wordpress,PHPMyAdmin等)的更新.
>只允许在使用PHPMyAdmin时访问它.这可以防止人们在您的安装上使用零日攻击.
>在将其用于任何类型的数据操作之前,验证存储在$_FILES中的文件名
>请注意,提供的mime类型可能是欺骗或其他错误
>将所有用户上传的文件移动到web root上面的目录中！
>不要使用include()执行/提供上传的文件
>尝试不提供内容类型为“application / octet-stream”,“application / unknown”或“plain / text”的文件
J.杂项……
>开发人员在开发站点/应用程序期间创建和使用Web根目录中的所有“实用程序”文件/程序,这些文件/程序无意或未被未来站点用户访问,或者存在某种安全风险,应该在网站上线时删除.
