php代码审计
工具：phpstorm + seay源代码审计系统
phpstorm 高效审计快捷键：
Ctrl + G 行号跳转
Ctrl + Alt + <-/-> 跳转返回/前进
Ctrl + 点击 查找函数/类/变量，定义或者使用
Ctrl + Shift + F 全局搜索字符串
Ctrl + Shift + N 全局搜索文件名
url路由：
1. apache，nginx等web服务器的配置实现路由，例如：
rewrite ^/([^/]+)/([^/]+)/.* /$1/$2/index.php last;
^/ : 以/开头
([^/]+)：分组$1，不是/的任意多个字符
([^/]+)：分组$2，不是/的任意多个字符
.* ： 任意多个字符
2. 通过程序代码进行url路由
sql注入防御：
1. PDO需要对用户输入参数进行bind
2. AR
参考链接：
1. YII框架的sql注入测试，与防范方法
2. Yii2中如果你这么写，可能造成sql注入漏洞
3. YII2安全之SQL注入和XSS攻击
4. Class yii\db\Connection，YII 2.0官方文档，有防注入的介绍
5. YII源码分析
6. 深入理解Yii2.0
-----------------------
7. Yii防止sql注入、xxs方法
8. 活动记录（Active Record）
-----------------------
9. 高级PHP应用程序漏洞审核技术
2018年6月19日星期二
2018年5月21日星期一
数据库审计
其实我们IT人员工作，经常会积累大量文档，如果不经常管理，你可能读完一篇文章或者文档，当时觉得受益很深，但是看完就过去了，久了有时候很难找到，或者放在一堆文件里面，需要逐个的打开看才能找到。我觉得，以后要养成一个好的习惯，创建一个【受益文档】的文件夹，里面放各种看过的文档，并且进行分类。这样以后要复习某一个知识点，就可以快速找到。
1. 数据库审计，首先需要知道需求，如果全部增删查改都审计，日志将会非常庞大，而select的审计量是占比最高的。
2. 数据库的审计方式，分为两种，一种是数据库自带的审计功能，另外一种是外部的数据库安全审计解决方案。自带的审计对服务器本身的消耗比较大，所以实际生产环境中主要采用外部的审计方式
根据需求进行审计是必要的，因为大量的无用的审计，只会消耗大量的资源，有针对性以及符合合规的审计需求，可保证不会浪费大量资源。
3. 根据需求，可分为
登录事件 （IP地址、用户名、客户端程序，时间），分为两类，成功登录、登录失败
登录失败可以实施警告或者账户锁定
审计正常操作时间之外的数据库使用，因为下班时间所进行的操作活动都是可疑的
审计DDL（数据描述语言）的活动
从安全的观点来看，DDL命令都是潜在的最具破坏力的命令，已被攻击者利用从而破坏系统。
DDL活动的审计是为了清除开发者和数据库管理员所引起的错误，以及一些可能会引起灾难影响的错误
审计数据库错误
攻击者可以使用基于union攻击，他需要猜测表的正确栏数，直到他得到正确的数字，数据库将不断的返回一个错误代码，表明select语句所选择的栏数不匹配。
审计特权、用户、登录定义
增加删除用户，角色
特权变更
口令变更
审计敏感数据的变更
对DML的审计也是一种常见的需求，使用这种审计方式，仍需小心，这很容易产生巨大的数据量。
1. 数据库审计，首先需要知道需求，如果全部增删查改都审计，日志将会非常庞大，而select的审计量是占比最高的。
2. 数据库的审计方式，分为两种，一种是数据库自带的审计功能，另外一种是外部的数据库安全审计解决方案。自带的审计对服务器本身的消耗比较大，所以实际生产环境中主要采用外部的审计方式
根据需求进行审计是必要的，因为大量的无用的审计，只会消耗大量的资源，有针对性以及符合合规的审计需求，可保证不会浪费大量资源。
3. 根据需求，可分为
登录事件 （IP地址、用户名、客户端程序，时间），分为两类，成功登录、登录失败
登录失败可以实施警告或者账户锁定
审计正常操作时间之外的数据库使用，因为下班时间所进行的操作活动都是可疑的
审计DDL（数据描述语言）的活动
从安全的观点来看，DDL命令都是潜在的最具破坏力的命令，已被攻击者利用从而破坏系统。
DDL活动的审计是为了清除开发者和数据库管理员所引起的错误，以及一些可能会引起灾难影响的错误
审计数据库错误
攻击者可以使用基于union攻击，他需要猜测表的正确栏数，直到他得到正确的数字，数据库将不断的返回一个错误代码，表明select语句所选择的栏数不匹配。
审计特权、用户、登录定义
增加删除用户，角色
特权变更
口令变更
审计敏感数据的变更
对DML的审计也是一种常见的需求，使用这种审计方式，仍需小心，这很容易产生巨大的数据量。
2018年5月7日星期一
基于OpenSSL自建CA和颁发SSL证书
浏览器是怎么验证，证书是来自权威CA发布的？
1.客户端向服务器端发起client hello，服务器端把证书发给客户端
2.证书包含：
a.域名的相关信息
b.站点的公钥
c.数字签名= CA_private_key( hash(a+b) )
3.浏览器在信任的权威CA里面寻找对应的颁发者证书，找出公钥，解密数字签名得到hash值
4.浏览器将证书包含的信息做一次hash，相当于 hash(a+b)，与3的hash值做对比，如果一样，就证明是正确的。
5.取出证书里面，站点使用的公钥，继续后面协商对称密钥的事务。
参考链接：
1. 基于OpenSSL自建CA和颁发SSL证书
2. OpenSSL 与 SSL 数字证书概念贴
3. SSL/TLS原理详解
4. 有关SSL证书的一些事儿
5. 证书的那些事儿
1.客户端向服务器端发起client hello，服务器端把证书发给客户端
2.证书包含：
a.域名的相关信息
b.站点的公钥
c.数字签名= CA_private_key( hash(a+b) )
3.浏览器在信任的权威CA里面寻找对应的颁发者证书，找出公钥，解密数字签名得到hash值
4.浏览器将证书包含的信息做一次hash，相当于 hash(a+b)，与3的hash值做对比，如果一样，就证明是正确的。
5.取出证书里面，站点使用的公钥，继续后面协商对称密钥的事务。
参考链接：
1. 基于OpenSSL自建CA和颁发SSL证书
2. OpenSSL 与 SSL 数字证书概念贴
3. SSL/TLS原理详解
4. 有关SSL证书的一些事儿
5. 证书的那些事儿
2018年3月1日星期四
ASA 5512 的拒绝服务故障排错
最近ASA 5512总是经过一段时间就不能工作，外网连接不上，经常报错误
%ASA-5-321001: Resource 'conns' limit of 100000 reached for system
通过show resource usage 看conns的当前数值以及最高峰值
show conn 通过xshell，编辑-->记事本-->全部
把数据导出到文本，然后放入linux shell下进行分析
参考链接：
1. cisco asa top connection
%ASA-5-321001: Resource 'conns' limit of 100000 reached for system
通过show resource usage 看conns的当前数值以及最高峰值
Resource Current Peak Limit Denied Context SSH 1 2 5 0 System ASDM 0 1 30 0 System Syslogs [rate] 124 12661 N/A 0 System Conns 19340 19504 100000 0 System Xlates 13410 13531 N/A 0 System Hosts 4977 4977 N/A 0 System Conns [rate] 73 729 N/A 0 System Inspects [rate] 29 728 N/A 0 System Routes 7 10 unlimited 0 System登录防火墙，并且在xshell等终端把缓冲设置到最大值200000
show conn 通过xshell，编辑-->记事本-->全部
把数据导出到文本，然后放入linux shell下进行分析
查看源IP地址，这里得出的总数值 约等于 show resouce usage 的 conns 当前值
cat conn.txt | awk '{print $5}' | awk '{FS = ":"}; {print $1}' | sort -n | uniq -c | sort -nr | head -10
查看目的IP地址
cat conn.txt | awk '{print $3}' | awk '{FS = ":"}; {print $1}' | sort -n | uniq -c | sort -nr | head -10
查看单个IP的连接数
show local-host 172.16.5.163 brief
清除所有连接
clear local all
如果需要快速将问题机器从网络中取出，您可以执行以下操作：
shun xxx.xxx.xxx.xxx
要扭转这种情况：
no shun xxx.xxx.xxx.xxx
参考链接：
1. cisco asa top connection
2018年2月26日星期一
wordpress目录迁移、上传限制修改
之前下载wordpress后，直接在web服务器文档根目录（DocumentRoot）解压
默认WordPress把上传文件的大小限制在2M
要解除这个限制，在后台插件模块，直接搜索Upload Max File Size
然后下载这个插件，配置很简单，只需要计算后输入数字就可以了。
然后重启httpd服务，如果不行就重启服务器
还有一种方法是修改 php.ini 配置文件
memory_limit=128M //相当于单个脚本可调用内存大小
post_max_size=8M //上传文件大小上限
upload_max_filesize=2M //默认上传文件大小，这个就是2M的限制！
max_execution_time=30 //最大执行时间，页面等待时间
max_input_time=60 //最大输入时间？具体意义不明确，就是上传时间相关
参考链接：
最后WordPress的文档目录
/webdata/wordpress/
但是在httpd.conf的DocumentRoot webdata，这样80端口打开后就是在webdata下
现在要将wordpress下的页面文件迁移到webdata下
实现方法：
mv wordpress/* /webdata
然后在/wp-admin/options-general.php配置到正确的路径
默认WordPress把上传文件的大小限制在2M
要解除这个限制，在后台插件模块，直接搜索Upload Max File Size
然后下载这个插件，配置很简单，只需要计算后输入数字就可以了。
然后重启httpd服务，如果不行就重启服务器
还有一种方法是修改 php.ini 配置文件
memory_limit=128M //相当于单个脚本可调用内存大小
post_max_size=8M //上传文件大小上限
upload_max_filesize=2M //默认上传文件大小，这个就是2M的限制！
max_execution_time=30 //最大执行时间，页面等待时间
max_input_time=60 //最大输入时间？具体意义不明确，就是上传时间相关
参考链接：
2018年1月18日星期四
树莓派2-B 安装 Ubuntu-Mate, 设置console
编辑TF卡中的文件
在config.txt文件中添加
cmdline文件修改成
参考链接：
（一）树莓派上手 （无（/有）显示器 串口连接 ）
在config.txt文件中添加
dtoverlay=pi3-miniuart-bt
cmdline文件修改成
dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
（原：dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh quiet splash plymouth.ignore-serial-consoles）
参考链接：
（一）树莓派上手 （无（/有）显示器 串口连接 ）
2018年1月12日星期五
linux最小权限原则
研究linux进程权限控制相关的课题，（本课题属于主机加固范围）
0x01 前言
最近接收到一个研究进程权限的课题，但是最后发现这块知识属于基础性的，想真正应用这项研究的成果还是很有限的，作为一个Linux用户来说，我们并不需要特别关心上面的机制。但是，当我们去编写一个Linux应用程序的时候，就要注意在程序中实现以上切换(有必要的前提下)，以便让我们的程序符合"最小权限"的原则，不给系统留下可能的安全隐患。
最小权限带来的好处：
1. 更好的系统稳定性
2. 更好的系统安全性
3. 更容易部署
0x02 linux权限组成
基本权限
r 、w、x
可以通过chmod改变
进程去执行任务的时候需要得到相应的权限，实际上，每个进程维护如下6个ID:
RUID 真实身份: real UID, real GID
EUID 有效身份: effective UID, effective GID
SUID 存储身份: saved UID, saved GID
真实身份：我们登录使用的身份
有效身份：当该进程真正去操作文件时所检查的身份
存储身份：当我们将一个程序文件执行成为进程的时候，该程序文件的拥有者(owner)和拥有组(owner group)可以被，存储成为进程的存储身份
并不是所有的程序文件在执行的过程都设置存储身份的。需要这么做的程序文件会在其九位(bit)权限的执行位的x改为s。这时，这一位(bit)叫做set UID bit或者set GID bit。
$ls -l /usr/bin/uuidd
-rwsr-sr-x 1 libuuid libuuid 17976 Mar 30 2012 /usr/sbin/uuidd
当我以root(UID), root(GID)的真实身份运行这个程序的时候，由于拥有者(owner)有s位的设定，所以saved UID被设置成为libuuid，saved GID被设置成为libuuid。这样，uuidd的进程就可以在两个身份之间切换。
我们通常使用chmod来修改set-UID bit和set-GID bit:
$chmod 4700 file
我们看到，这里的chmod后面不再只是三位的数字。最前面一位用于处理set-UID bit/set-GID bit，它可以被设置成为4/2/1以及或者上面数字的和。4表示为set UID bit, 2表示为set GID bit，1表示为sticky bit (暂时不介绍)。必须要先有x位的基础上，才能设置s位。
开机后，linux内核加载的时候，首先开始执行进程init，而且是root权限运行的，然后通过
fork函数去加载其他用户进程。
而sudo这个程序，默认就设置了suid
0x03 限制进程所创建文件的权限属性
umask 表示操作系统不允许设置的权限位
037 --> --- -wx rwx
640 --> rw- r-- ---
不允许创建的文件有执行的权限
0x04 web应用系统可写目录的权限控制
Nginx
数据缓存目录 cache，这个目录的特点是需要777 权限，无须提供给用户访问
附件上传目录 attachments，此目录的特点是需要开放访问权限，但所有文件不能由php 引擎解析（包括后缀名改为 gif 的木马文件）
静态文件生成目录 public，这些目录一般都是php 生成的静态页的保存目录，显然与附件目录有类似之处，按附件目录的权限设置即可。可以预见的是，如果我们设置了较严格的权限，即使网站php 程序存在漏洞，木马脚本也只能被写入到权限为 777 的目录中去，如果配合上述严格的目录权限控制，木马也无法被触发运行，整个系统的安全性显然会有显著的提高。
Apache
建立安全的apache的目录结构。ServerRoot DocumentRoot ScripAlias Customlog Errorlog 均放在单独的目录环境中。以上主要目录相互独立并且不存在父子逻辑关系。
ServerRoot目录只能具有管理权限用户访问；DocumentRoot能够被管理Web站点内容的用户访问和使用Apache服务器的Apache用户和Apache用户组访问；只有admin组的用户可以访问日志目录。 各个目录设置独立的权限
上传目录设置php文件解析限制
配置Apache防止webshell上传
0x05 web服务进程的权限配置
以Nobody用户运行
一般情况下，Apache是由Root 来安装和运行的。如果Apache Server进程具有Root用户特权，那么它将给系统的安全构成很大的威胁，应确保Apache Server进程以最可能低的权限用户来运行。通过修改httpd.conf文件中的下列选项，以Nobody用户运行Apache 达到相对安全的目的。
User nobody
参考链接：
1. linux用户与“最小权限”原则
2. linux文件管理
3. linux进程基础
4. 最小特权原则
5. 正确设置php-fpm子进程用户，提高网站安全性防挂马
6. linux下apache安全配置策略
7. 探秘linux权限控制
8. Linux 权限管理与访问控制详解(1)——基本概念和 DAC
9. Linux 权限管理与访问控制详解(2)——MAC 和 SELinux
10. apache运行机制剖析
11. Linux權限控制的基本原理
12. nginx、php-fpm、mysql用户权限解析
13. 企业级Linux系统下的进程安全管理方法
0x01 前言
最近接收到一个研究进程权限的课题，但是最后发现这块知识属于基础性的，想真正应用这项研究的成果还是很有限的，作为一个Linux用户来说，我们并不需要特别关心上面的机制。但是，当我们去编写一个Linux应用程序的时候，就要注意在程序中实现以上切换(有必要的前提下)，以便让我们的程序符合"最小权限"的原则，不给系统留下可能的安全隐患。
最小权限带来的好处：
1. 更好的系统稳定性
2. 更好的系统安全性
3. 更容易部署
0x02 linux权限组成
基本权限
r 、w、x
可以通过chmod改变
chmod # 更改文件或者目录权限
二进制设置
644 --> 110 100 100 --> rw- r-- r--
755 --> 111 101 101 --> rwx r-x r-x
(八进制 - 二进制) (二进制 - 实际含义)
字符设置
+---------+-------+-----+
| u user | | |
|---------| + | r |
| g group |-------|-----|
|---------| - | w |
| o other |-------|-----|
|---------| = | x |
| a all | | |
+---------+-------+-----+
0x02 认识进程权限进程去执行任务的时候需要得到相应的权限，实际上，每个进程维护如下6个ID:
RUID 真实身份: real UID, real GID
EUID 有效身份: effective UID, effective GID
SUID 存储身份: saved UID, saved GID
真实身份：我们登录使用的身份
有效身份：当该进程真正去操作文件时所检查的身份
存储身份：当我们将一个程序文件执行成为进程的时候，该程序文件的拥有者(owner)和拥有组(owner group)可以被，存储成为进程的存储身份
并不是所有的程序文件在执行的过程都设置存储身份的。需要这么做的程序文件会在其九位(bit)权限的执行位的x改为s。这时，这一位(bit)叫做set UID bit或者set GID bit。
$ls -l /usr/bin/uuidd
-rwsr-sr-x 1 libuuid libuuid 17976 Mar 30 2012 /usr/sbin/uuidd
当我以root(UID), root(GID)的真实身份运行这个程序的时候，由于拥有者(owner)有s位的设定，所以saved UID被设置成为libuuid，saved GID被设置成为libuuid。这样，uuidd的进程就可以在两个身份之间切换。
我们通常使用chmod来修改set-UID bit和set-GID bit:
$chmod 4700 file
我们看到，这里的chmod后面不再只是三位的数字。最前面一位用于处理set-UID bit/set-GID bit，它可以被设置成为4/2/1以及或者上面数字的和。4表示为set UID bit, 2表示为set GID bit，1表示为sticky bit (暂时不介绍)。必须要先有x位的基础上，才能设置s位。
开机后，linux内核加载的时候，首先开始执行进程init，而且是root权限运行的，然后通过
fork函数去加载其他用户进程。
而sudo这个程序，默认就设置了suid
0x03 限制进程所创建文件的权限属性
umask 表示操作系统不允许设置的权限位
037 --> --- -wx rwx
640 --> rw- r-- ---
不允许创建的文件有执行的权限
0x04 web应用系统可写目录的权限控制
Nginx
数据缓存目录 cache，这个目录的特点是需要777 权限，无须提供给用户访问
附件上传目录 attachments，此目录的特点是需要开放访问权限，但所有文件不能由php 引擎解析（包括后缀名改为 gif 的木马文件）
静态文件生成目录 public，这些目录一般都是php 生成的静态页的保存目录，显然与附件目录有类似之处，按附件目录的权限设置即可。可以预见的是，如果我们设置了较严格的权限，即使网站php 程序存在漏洞，木马脚本也只能被写入到权限为 777 的目录中去，如果配合上述严格的目录权限控制，木马也无法被触发运行，整个系统的安全性显然会有显著的提高。
Apache
建立安全的apache的目录结构。ServerRoot DocumentRoot ScripAlias Customlog Errorlog 均放在单独的目录环境中。以上主要目录相互独立并且不存在父子逻辑关系。
ServerRoot目录只能具有管理权限用户访问；DocumentRoot能够被管理Web站点内容的用户访问和使用Apache服务器的Apache用户和Apache用户组访问；只有admin组的用户可以访问日志目录。 各个目录设置独立的权限
上传目录设置php文件解析限制
配置Apache防止webshell上传
0x05 web服务进程的权限配置
以Nobody用户运行
一般情况下，Apache是由Root 来安装和运行的。如果Apache Server进程具有Root用户特权，那么它将给系统的安全构成很大的威胁，应确保Apache Server进程以最可能低的权限用户来运行。通过修改httpd.conf文件中的下列选项，以Nobody用户运行Apache 达到相对安全的目的。
User nobody
参考链接：
1. linux用户与“最小权限”原则
2. linux文件管理
3. linux进程基础
4. 最小特权原则
5. 正确设置php-fpm子进程用户，提高网站安全性防挂马
6. linux下apache安全配置策略
7. 探秘linux权限控制
8. Linux 权限管理与访问控制详解(1)——基本概念和 DAC
9. Linux 权限管理与访问控制详解(2)——MAC 和 SELinux
10. apache运行机制剖析
11. Linux權限控制的基本原理
12. nginx、php-fpm、mysql用户权限解析
13. 企业级Linux系统下的进程安全管理方法
订阅：
博文 (Atom)