Fotify|代码审计静态扫描工具，商业化静态代码扫描工具，误报率相对较低。
seay|源代码审计工具
CodeQl | 高效的QL非商业的开源代码自动化审计工具。
xcheck| Xcheck 是一款静态运用安全测试工具，旨在及时创造业务代码中的安全风险，尤其是由不受信输入所触发的安全漏洞。检测范围覆盖主流 Web 安全漏洞，具备速率快、误报低和准确率高档优点。
chrome & HackerBar插件00×3 明确目标在审计之前，我们首先先确定自己这次审计的目地，我以为会有三种情形
为了提升自己的审计履历项目中为了审计出能进一步利用的漏洞，一样平常须要getshell、ssrf这种级别的。为了挖点洞，去换钱或者换cve&cnvd。有什么差异呢？
为了提升审计履历，我会去重点关注历史漏洞，并去复现。
如果是为了能审出漏洞，去用作渗透中的进一步利用，那么我以为，可以重点利用xcheck、Fotify等自动化代码审计，然后关注下面的文件上传、包含、sql注入等等有严重危害的漏洞
如果是为了挖0day，搞证书什么的，那么全方位按步骤过一遍，是不错的选择。
【一>所有资源关注我，私信回答“资料”获取<一】1、200份很多已经买不到的绝版电子书2、30G安全大厂内部的视频资料3、100份src文档4、常见安全口试题5、ctf大赛经典题目解析6、全套工具包7、应急相应条记8、网络安全学习路线
00×4 判断是否是用了框架判断是否利用了框架，是蛮主要的，能帮助我们快速定位有用的函数集，筛选不须要去看的代码。
一样平常来说，我以为利用了框架的更好审计一点，由于利用了框架的，他的函数集文件（各种方法function）会比较规整，在某些固定文件夹中，清晰可见，当然须要我们先对框架有所理解。
目前比较主流的设计模式是MVC，即多层模型（M）、视图（V）、掌握器（C），在此不多赘述，php的主流框架险些都利用了MVC设计模式。
PHP底下的开拓框架目前见的比较多的有Laravel，ThinkPHP，yii等。
4.1. ThinkPHP框架ThinkPHP这里须要区分TP3和TP5的差别，首先我们先来看看TP3的目录构造。（现在基于TP3的系统都很少了。。。理解一下就好
个中，Application和Public目录下面都是空的。
Application是存放项目中的主要的一些函数集，Public是公共文件夹，供用户访问的，主要的函数集千万不能放在此文件夹下。
Application目录默认是空的，但是第一次访问入口文件会自动天生，参考后面的入口文件部分。个中框架目录ThinkPHP的构造如下：
其余TP5和TP3实际上差距有点大，先看看TP5下载下来的默认文件构造。个中在public文件下有个route.php文件，它的浸染是用于php自带webserver支持，可用于快速测试，启动命令：php -S localhost:8888 router.php。而它的干系网站功能目录也须要从根目录下的index.php入手。
以下为TP5的目录构造。
一样平常如果是审计基于框架的cms，我不会去看框架系统目录，便是上面的ThinkPHP文件夹下的东西，第三方类库vendor也不会去先看，除非是在审计过程中流向了这些文件中，才会大概看一看，而重点在Application文件夹下做文章。
既然是MVC框架的，那么我们真正关心的是个中的掌握器（C），由于功能点大部分都在C上，我们能找到的大部分漏洞也都在C上
下图为基于TP6的ThinkAdmin项目目录
app（也便是application），下面有admin、data、index、wechat几个文件夹，每个文件夹代表了一个运用，比如admin一样平常来说都是后台的做事，wechat为微信运用做事，每个运用下面都有Controller（掌握器）、Module（模型）、View（视图，一样平常是html文件）
现在目录很明确，目标就很明确，拿到这样基于框架的cms，就该当知道，该重点审计的地方在哪里。
4.2. Laravel框架目录怎么变，MVC架构的重点还是在Controllers里
4.3. 如果没用框架没用框架的话，先搞明白目录构造，一样平常来说
审计过程中须要关注几个点：（在我们后面开始审计的过程中，自己要把稳这些地方，常常想一想）
1）函数集文件，常日命名包含function或者common等关键字，这些文件里面是一些公共的函数，供应其他文件统一调用，以是大多数文件都会在文件头部包含到其他文件。探求这些文件一个非常好用的技巧便是去打开index.php或者一些功能性文件，在头部一样平常都能找到。
2）配置文件，常日命名中包括config关键字，配置文件包括web程序运行必须的功能性配置选项以及数据库等配置信息。从这个文件中可以理解程序的小部分功能，其余看这个文件的时候把稳不雅观察配置文件中参数值是单引号还是用双引号括起来，如果是双引号可能就存在代码实行的问题了。
3）安全过滤文件，安全过滤文件对代码审计至关主要，这关系到我们挖掘到的可以点能否直策应用，常日命名中带有filter、safe、check等关键字，这类文件紧张是对参数进行过滤，大多数的运用实在会在参数的输入做一下addslashes()函数的过滤。
4）index文件，index是一个程序的入口，以是常日我们只要读一读index文件就可以大致理解全体程序的架构、运行的流程、包含到的文件，个中核心的文件有哪些。而不同目录的index文件也有不同的实现办法，建议最好将几个核心目录的index文件都通读一遍。
00×5 理解路由我很喜好Thinkphp这类框架的缘故原由是，他们的路由很好摸清，如果在哪个方法中找到了漏洞，我就能直接根据路由访问这个方法，直策应用。
理解路由也是为了能快速定位漏洞位置，要不然，你通过审计源码找到的漏洞，却不知道在浏览器中用什么样的url去访问，这不是件很尴尬的事儿吗？
比如Thinkphp的路由有三种办法5.1. 普通模式关闭路由，完备利用默认的pathinfo办法URL：
‘url_route_on’ => false,
路由关闭后，不会解析任何路由规则，采取默认的PATH_INFO 模式访问URL：
module/controller/action/param/value/…
module便是利用的运用。
controller是掌握器，跟文件名同等。
action是方法，某掌握器下的方法。
param是须要的变量
value是参数
但仍旧可以通过Action参数绑定、空掌握器和空操作等特性实现URL地址的简化
5.2. 稠浊模式开启路由，并利用路由+默认PATH_INFO办法的稠浊：
‘url_route_on’ => true,
该办法下面，只须要对须要定义路由规则的访问地址定义路由规则，其它的仍旧按照默认的PATH_INFO模式访问URL。
5.3. 逼迫模式开启路由，并设置必须定义路由才能访问：
‘url_route_on’ => true,‘url_route_must’=> true,
这种办法下面必须严格给每一个访问地址定义路由规则，否则将抛出非常。
首页的路由规则是 /。
实在，在实际审计过程中，我一样平常会先去黑盒访问一遍功能点，剖析后差不多也能知道路由若何构成，如果有的地方不清楚，可以去源码中找路由文件
一样平常带有route关键词的文件，或文件夹与路由有关。
剖析好路径，之后就可以真正的开始审计。
00×6 审计在人工审计之前，可以利用我之条件到的xcheck、Fotify、codeql等自动化审计工具先审计一遍，根据报告，验证一遍，再往下去根据下面的步骤审一遍，一个项目，也就能审个七七八八了，深层次的利用也就得看自身的实力与履历了。
如果利用了框架，可以先看看此项目还有没有框架的漏洞存在，我就不再赘述了。
6.1. 鉴权首先对付项目整体的一个权限认证做一个判断，判断是否存在越权，未授权访问的情形。
一样平常来说，须要权限认证的地方，是后台管理，即admin运用下的。
以是对付admin下的掌握器这些方法，须要判断是否可以未授权访问。
目前对付全体后台管理鉴权的办法，一样平常是采取写一个基类，比如Base.php或者common.php，个中存在鉴权方法，然后在每个掌握器类继续这个类。
比如xiaohuanxiong漫画cms的后台，便是采取了这种方法。
不过我也看到了，有的比较好的项目，自己二开框架，做了自己的组件，然后，每个类都继续了此组件，也是同样的事理
比如ThinkAdmin，继续了自己组件的controller。
我们知道了鉴权的办法，以是我们首先看的是，如果他没有这些鉴权办法，或者其他鉴权办法也没有，那么他就会存在未授权访问，即不登录也能访问后台功能。这是很危险的，一个是管理员才能看到的敏感信息，未授权就能看到，更危险的是，结合后台的漏洞，直接未授权getshell也是很有可能的，以是鉴权我们首先去看，而且随意马虎去看的地方。
6.2. 按照漏洞类型审计我认为对付我来说，比较好的审计方法是黑盒白盒一起，根据漏洞类型一个一个的去找寻可能存在漏洞的地方，然后再回溯查看是否用户可控，以此快速定位漏洞。
以是一样平常我是根据漏洞类型，以及每个漏洞可能涉及的危险函数，去快速定位。
那一样平常看的地方有SQL注入、XSS、CSRF、SSRF、XML外部实体注入等等
6.2.1. sql注入如果利用了框架，可以分辨一下框架名称以及版本，去搜索一下该版本的框架是否存在漏洞，如果存在再去cms中验证。由于本篇文章紧张讲我自己在cms审计上的一些履历，因此不多深入框架的审计部分。如果没有利用框架，则须要仔细的不雅观察数据库函数，一样平常来说，cms是将select、insert等函数进行了封装的，比如$db->table(‘test’)->where(“name=admin”)便是select from test where name=admin这种格式，而此时若是创造cms利用的是过滤+拼接，那么很有可能会涌现问题，而如果利用了PDO，则连续跟进涉及到table，order by等字段的拼接去，由于这些字段是无法利用PDO的。审计要素：
参数是否用户可控是否利用了预编译那么首先，如果没有利用框架封装的sql语句，那么全局搜索insert、select等sql语句关键词，然后定位到详细的语句，然后查看里面有没有拼接的变量，回溯可不可控。如果可控并且存在字符串拼接，很有可能就存在漏洞。
利用了框架的便是搜索的关键词不一样，还是得看是否存在字符串拼接，可不可控。
纵然利用了预编译，但是如果在预编译之前字符串拼接了，那还是没有鸟用，该注入还是能注入。
下面供应一样平常我会搜索的关键词（框架的根据你审计项目的框架的手册，自行搜索。）师傅们有想补充的也可以补充。
insertcreatedeleteupdateorder bygroup bywherefromlimitdescascunionselect6.2.2. xss漏洞
审计要素
是否存在全局参数过滤器，过滤规则是否符合安全哀求，是否存在需过滤和不需过滤两种输出，页面是否掌握恰当。输出时是否进行编码（HTML、JS等）。前端是否采取了Angularjs、React、vue.js等具有XSS防护功能的前端框架进行数据输出。这个的话，我就不会关键词搜了，我便是会在探求其他漏洞的过程中，把稳有没有直接把输入原样输出的地方，也没有特殊关注这一块。
如果想特意挖掘这一块，可以
查看是否配置了全局的拦截器、过滤器。检讨数据输出函数，例如常用的输出函数有print、print_r、echo、printf、sprintf、die、var_dump、var_export。
6.2.3. CSRF漏洞与XSS攻击比较，CSRF攻击每每不大盛行（因此对其进行戒备的资源也相称稀少）和难以戒备，以是被认为比XSS更具危险性。
审计要素
是否在表单处存在随机token。是否存在敏感操作的表单。CSRF紧张利用场景实际上是一些越权的操作，或者一些敏感功能存在的地方，例如管理后台、会员中央等地方。我们可以考试测验搜索表单位置，查看是否会天生随机token，在查看后端代码中是否会先验证这部分的token。如果没有验证token，再进一步看看是否有refer的干系验证，如果没有，那么就存在CSRF的问题。
可以考试测验全局搜索
csrf-tokencsrf_tokencsrftokencsrf
下面是一个更新密码的操作，假设布局一个链接为 http://127.0.0.1/index.php?password_new=password&password_conf=password&Change=Change#的链接，直接发送给受害者点击，那么当前情形下，可以直接修正受害者的密码，由于没有进行任何的验证方法。当然一样平常代码不会这么写，只是拿DVWA的CSRF举个例子。
6.2.4. SSRF漏洞
ssrf是利用存在毛病的web运用作为代理攻击远程和本地的做事器。常见的办法如下：
1.可以对外网、做事器所在内网、本地进行端口扫描，获取一些做事的banner信息;
2.攻击运行在内网或本地的运用程序（比如溢出）;
3.对内网web运用进行指纹识别，通过访问默认文件实现;
4.攻击内外网的web运用，紧张是利用get参数就可以实现的攻击（比如struts2，sqli等）;
5.利用file协议读取本地文件等。
审计要素:
是否存在可以产生SSRF漏洞的函数。是否存在内网ip地址正则过滤，且正则是否严谨。是否存在限定要求的办法只能为HTTP或者HTTPS。当然PHP底下常常可能会涌现SSRF漏洞的紧张有几个函数，它们分别是file_get_contents()、fsockopen()、curl_exec()、get_headers()。通过全文关键函数搜索，在看是否限定了访问端口，访问协议，内网ip地址等。
利用file://、http/https:// 、dict://、gopher://协议去搞内网。
列一下，我常常搜索的关键词
file_get_contentsfsockopencurl_execget_headersfopenreadfile
把稳
一样平常情形下PHP不会开启fopen的gopher wrapperfile_get_contents的gopher协议不能URL编码file_get_contents关于Gopher的302跳转会涌现bug，导致利用失落败curl/libcurl 7.43 上gopher协议存在bug(%00截断) 经测试7.49 可用curl_exec() //默认不跟踪跳转，file_get_contents() // file_get_contents支持 php://input协议各种绕过，我就不在这说了。
6.2.5. XML外部实体注入审计要素
参数是否用户可控是否libxml版本为2.9.0以上是否禁用了外部实体这个一样平常我关注的少，仅仅是搜索“DOMDocument”，“SimpleXMLElement”和“simplexml_load_string”等关键词，剖析下是否存在参数拼接的XML字符串，或未做限定的批量解析方法。对参数进行回溯，判断其是否用户可控。
6.2.6. 文件包含漏洞审计要素
参数是否用户可控是否存在include，require，include_once, require_once等函数。文件包含算是拿shell最快的方法了，以是一样平常要重点关注。
无非是include，require，include_once, require_once这四个函数，全局搜索这四个函数，一个一个去看，去回溯，查看变量可不可控。
6.2.7. 文件上传漏洞审计要素
是否检讨了上传文件的文件类型是否限定了文件上传路径是否对文件进行了重命名文件大小是否限定是否返回了文件路径或文件路径很好预测有的项目，会对文件上传下载进行分装，以是可以全局搜索有关upload、file的函数，看看是不是封装了
function uploadfunction file
如果封装了，那么就看这些封装好的函数，有没有上面提到的审计要素的漏洞。
如果没封装，一样平常是move_uploaded_file这个函数，全局搜索，这个函数，回溯查看这些漏洞存不存在。（白盒黑盒一起搞比较好。）
6.2.8. 变量覆盖审计要素
是否存在造成变量覆盖的函数，例如：extract()、parse_str()、import_request_variables和$$等。是否存在可以完全利用的攻击链。一样平常就这几个函数和关键词
extractparse_strimport_request_variablesmb_parse_str$$
不过还有个分外的配置，也可能造成变量覆盖
register_globals全局变量覆盖
php.ini中有一项为register_globals，即注册全局变量，当register_globals=On时，通报过来的值会被直接的注册为全局变量直策应用，而register_globals=Off时，我们须要到特定的数组里去得到它。
把稳：register_globals已自 PHP 5.3.0 起废弃并将自 PHP 5.4.0 起移除。
当register_globals=On，变量未被初始化且能够用户所掌握时，就会存在变量覆盖漏洞：
<?phpecho “Register_globals: “ . (int)ini_get(“register_globals”) . “<br/>“;if ($a) {echo “Hacked!”;}?>
通过GET和POST办法输入变量a的值：
当然，也可以从COOKIE中输入：
6.2.9. 代码实行漏洞
审计要素
php.ini文件中的disable_function是否有禁用函数。是否存在代码实行的敏感函数。是否输入变量可控。全局搜索下面的关键词，回溯参数可不可控。
evalasserpreg_replacecreate_functionarray_mapcall_user_funccall_user_func_arrayarray_filterusortuasort$a($b)（动态函数）6.2.10. 命令实行漏洞
审计要素
参数是否用户可控是否配置了全局过滤器，过滤规则是否符合安全规范是否所有的命令实行参数都经由了过滤器，或受白名单限定全局搜索下面的关键词，回溯参数可不可控。
execpassthruproc_openshell_execsystempcntl_execpopen
“（被反引号包裹的变量也可以实行）
6.2.11. 任意文件下载/下载漏洞审计审计要素
是否存在…/、.、…\等分外字符过滤。参数是否用户可控是否配置了相对路径或者绝对路径。查询这些关键词，查看变量是否可控，是否有过滤
fgetsfgetssfile_get_contentsreadfileparse_ini_filehighlight_filefilefopenreadfilefread
Tip:前两天碰着个，过滤了config/database.php这样的正则匹配，还过滤了…，目的是防止目录穿越，读取做事器其他目录的文件，可是没过滤一个.
这样我利用config/./database.php绕过了正则，还是把敏感文件读取出来了。。。
6.2.12. 任意文件删除和上面的下载一样
搜索的关键词变了
rmdirunlink6.2.13. 任意文件写入
还是一样，关键词为
copyfile_put_contentsfwrite6.2.14. 会话认证漏洞
会话认证漏洞实际上涉及的方面比较广，如cookie、session、sso、oauth等，当然这个漏洞比较常见是在cookie上，做事端直接取用cookie中的数据而没有校验，其次是cookie加密数据在可预测的情形下。
审计要素
是否cookie中的加密数据可预测。是否cookie中的数据可预测。做事端是否只依赖cookie来判断用户身份。全局去探求cookie天生的逻辑，判断是否可预测，判断用户身份是否只依赖cookie，而不是随机的，比如
鉴权是只通过cookie中的userid来判断，如果我遍历userid，可以达到登录绕过或越权的目地。
6.2.15. 反序列化漏洞一样平常实际审计的时候，项目中见的比较少，框架中见的比较多。
全局搜索serialize。看看存不存在可控变量。
