《白帽子讲web安全》

第十四章 PHP安全

文件包含漏洞是“代码注入”的一种。“代码注入”这种攻击,其原理就是注入一段用户能控制的脚本或代码,并让服务器端执行。“代码注入”的典型代表就是文件包含(File Inclusion)。文件包含可能会出现在JSP、PHP、ASP等语言中
常见的导致文件包含的函数如下。
PHP:include(), include_once(), require(), require_once(), fopen(), readfile(), …
JSP/Servlet:ava.io.File(), java.io.FileReader(), …
ASP:include file, include virtual, …

文件包含是PHP的一种常见用法,主要由4个函数完成:include()require()include_once()require_once()
当使用这4个函数包含一个新的文件时,该文件将作为PHP代码执行,PHP内核并不会在意该被包含的文件是什么类型。所以如果被包含的是txt文件、图片文件、远程URL,也都将作为PHP代码执行

本地文件包含

《白帽子讲web安全》_第1张图片
将test.php文件放到已配置到的web服务器所在目录,直接使用url即可访问并执行该php文件
文件内容为

  
include ($_GET[test]);
?>

《白帽子讲web安全》_第2张图片
包含该目录下的文件,这个文件在目录是不存在的,所以提示没找到。
那么访问一个存在的文件如a.txt,内容为


	phpinfo();
?>

《白帽子讲web安全》_第3张图片
可以看到该txt文件中的函数已经被执行了。
要想成功利用文件包含漏洞,需要满足下面两个条件:
(1)include()等函数通过动态变量的方式引入需要包含的文件;
(2)用户能够控制该动态变量。

能够打开并包含本地文件的漏洞,被称为本地文件包含漏洞(Local File Inclusion,简称LFI)
使用了“…/…/…/”这样的方式来返回到上层目录中,这种方式又被称为“目录遍历,php设置open_basedir可以预防目录遍历
要解决文件包含漏洞,应该尽量避免包含动态的变量,尤其是用户可以控制的变量。可以使用白名单,枚举可以被包含的文件

远程文件包含

如果PHP的配置选项allow_url_include为ON的话,则include/require函数是可以加载远程文件的,这种漏洞被称为远程文件包含漏洞(Remote File Inclusion,简称RFI)。如图可见提示all_url_include=0所以不允许包含http远程地址。
《白帽子讲web安全》_第4张图片
在php.ini文件设置
《白帽子讲web安全》_第5张图片
如果远程地址的文件包含可执行代码,则会被执行。

第十七章 安全的开发流程 SDL

安全开发流程,能够帮助企业以最小的成本提高产品的安全性。它符合“Secure at the Source”的战略思想.
SDL的全称是Security Development Lifecycle,即:安全开发生命周期。它是由微软最早提出的,在软件工程中实施,是帮助解决软件安全问题的办法
自2004年起,SDL一直都是微软在全公司实施的强制性策略。SDL的大致步骤如下
《白帽子讲web安全》_第6张图片

  • 培训
    开发团队的所有成员都必须接受适当的安全培训,覆盖安全设计,威胁建模、安全编码、安全测试、隐私等。
  • 安全要求
    在项目确立之前,需要提前与项目经理或者产品owner进行沟通,确定安全的要求和需要做的事情。
  • 质量门/bug栏
    质量门和bug栏用于确定安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解,并有助于团队在开发过程中发现和修复安全bug
  • 安全和隐私风险评估
  • 设计要求
    在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。
  • 减小攻击面
    减小攻击面包括关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可能地进行分层防御
  • 威胁建模
    为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。微软提出了STRIDE模型以帮助建立威胁模型
  • 使用指定的工具
    开发团队使用的编译器、链接器等相关工具,可能会涉及一些安全相关的环节
  • 静态分析
    代码静态分析可以由相关工具辅助完成,其结果与人工分析相结合。
  • 动态分析
    动态程序分析动态分析是静态分析的补充,用于测试环节验证程序的安全性。
  • 模糊测试
    模糊测试(Fuzzing Test)
  • 威胁模型和攻击面评析
  • 事件响应计划
  • 最终安全评析
    最终安全评析(FSR)是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同结果。❍ 通过FSR。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解。❍ 通过FSR但有异常。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解,并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来,在下次发布时更正。❍ 需上报问题的FSR。如果团队未满足所有SDL要求,并且安全顾问和产品团队无法达成可接受的折中,则安全顾问不能批准项目,项目不能发布。团队必须在发布之前解决所有可以解决的问题,或者上报高级管理层进行抉择。
  • 发布/存档
    相对于微软的SDL, OWASP推出了SAMM(Software Assurance Maturity Model)[插图],帮助开发者在软件工程的过程中实施安全。

敏捷SDL

微软为敏捷开发专门设计了敏捷SDL
《白帽子讲web安全》_第7张图片

你可能感兴趣的:(web安全,安全)