⑴ 文件上传漏洞攻击方法有什么
文件上传漏洞是什么？怎样防御文件上传漏洞攻击？文件上传漏洞是web安全中经常利用到的一种漏洞形式。这种类型的攻击从大的类型上来说，是攻击 数据与代码分离原则 的一种攻击。
一些web应用程序中允许上传图片，文本或者其他资源到指定的位置，文件上传漏洞就是利用这些可以上传的地方将恶意代码植入到服务器中，再通过url去访问以执行代码
造成文件上传漏洞的原因是
对于上传文件的后缀名（扩展名）没有做较为严格的限制
对于上传文件的MIMETYPE 没有做检查
权限上没有对于上传的文件的文件权限，（尤其是对于shebang类型的文件）
对于web server对于上传文件或者指定目录的行为没有做限制
下面就闲话一些文件上传漏洞的防御方式和攻击者的绕过方式
1.前端限制
function check(){
var filename=document.getElementById("file");
var str=filename.value.split(".");
var ext=str[str.length-1];
if(ext=='jpg'||ext=='png'||ext=='jpeg'||ext=='gif'){
return true;
}else{
alert("这不是图片！")
return false;
}
return false;
}
在表单中使用onsumbit=check()调用js函数来检查上传文件的扩展名。这种限制实际上没有任何用处，任何攻击者都可以轻而易举的破解。只能用于对于用户完全信任的情况下，很难称之为一种安全措施只能称之是一种防止用户误操作上传的措施，
反制：
随便的编辑一下页面/用burpsuite/写个小脚本就可以突破之，无须多言
2.检查扩展名
顾名思义，就是在文件被上传到服务端的时候，对于文件名的扩展名进行检查，如果不合法，则拒绝这次上传
在这里，还有一点是值得一提的，在检查扩展名是否合法的时候，有两种策略
黑名单策略，文件扩展名在黑名单中的为不合法,示例代码
$postfix = end(explode('.','$_POST['filename']);
if($postfix=='php'||$postfix=='asp'||$postfix=='sh'){
echo "invalid file type";
return;
}
白名单策略，文件扩展名不在白名单中的均为不合法
$postfix = end(explode('.','$_POST['filename']);
if($postfix=='jpg'||$postfix=='png'||$postfix=='gif'){
//save the file and do something next
} else {
echo "invalid file type";
return;
}
白名单策略是更加安全的，通过限制上传类型为只有我们接受的类型，可以较好的保证安全，因为黑名单我们可以使用各种方法来进行注入和突破
反制
在一些 webserver 中，存在解析漏洞
1.老版本的IIS中的目录解析漏洞，如果网站目录中有一个 /.asp/目录，那么此目录下面的一切内容都会被当作asp脚本来解析
2.老板本的IIS中的分号漏洞：IIS在解析文件名的时候可能将分号后面的内容丢弃，那么我们可以在上传的时候给后面加入分号内容来避免黑名单过滤，如 a.asp;jpg
3.旧版Windows Server中存在空格和dot漏洞类似于 a.php. 和 a.php[空格] 这样的文件名存储后会被windows去掉点和空格，从而使得加上这两个东西可以突破过滤，成功上传，并且被当作php代码来执行
4.nginx空字节漏洞 xxx.jpg%00.php 这样的文件名会被解析为php代码运行
5.apache的解析漏洞，上传如a.php.rar a.php.gif 类型的文件名，可以避免对于php文件的过滤机制，但是由于apache在解析文件名的时候是从右向左读，如果遇到不能识别的扩展名则跳过，rar等扩展名是apache不能识别的，因此就会直接将类型识别为php，从而达到了注入php代码的目的
3.检查HTTP Header中的Content-Type
HTTP协议规定了上传资源的时候在Header中加上一项文件的MIMETYPE，来识别文件类型，这个动作是由浏览器完成的，服务端可以检查此类型不过这仍然是不安全的,因为HTTP header可以被发出者或者中间人任意的修改，不过加上一层防护也是可以有一定效果的
反制
使用各种各样的工具（如burpsuite）强行篡改Header就可以，太容易将header中的
Content-Type: application/php
或者其他类型
改为
Content-Type: image/jpg
Content-Type: image/png
Content-Type: text/plain
等这些web程序允许的泪洗改附上常用的MIMETYPE表
text/plain（纯文本）
text/html（HTML文档）
text/javascript（js代码）
application/xhtml+xml（XHTML文档）
image/gif（GIF图像）
image/jpeg（JPEG图像）
image/png（PNG图像）
video/mpeg（MPEG动画）
application/octet-stream（二进制数据）
application/pdf（PDF文档）
application/(编程语言) 该种语言的代码
application/msword（Microsoft Word文件）
message/rfc822（RFC 822形式）
multipart/alternative（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
application/x-www-form-urlencoded（POST方法提交的表单）
multipart/form-data（POST提交时伴随文件上传的表单）
4.分析文件头内容来检查文件类型
与方法2不同，还有一种检查类型的方式是使用对于文件内容的验证机制，这种方法利用的是每一个特定类型的文件都会有不太一样的开头或者标志位。可以通过比如php的exif_imagetype()函数，一个通过这种方法来过滤的示例代码如下：
if (! exif_imagetype($_FILES['uploadedfile']['tmp_name'])) {
echo "File is not an image";
return;
}
也可以自己编写函数来进行识别，图片文件通常有称作幻数的头字节，我们来看一下几种图片文件的幻数：
（注意！下面是二进制而不是文本格式的数据）
JPG
FF D8 FF E0 00 10 4A 46 49 46
GIF
47 49 46 38 39 61
(相当于文本的GIF89a)
PNG
89 50 4E 47
通过检查头几位字节，可以分辨是否是图片文件
如果是其他类型的二进制文件，也有响应的头字节，如下表
反制
给上传脚本加上相应的幻数头字节就可以，php引擎会将
（一般不限制图片文件格式的时候使用GIF的头比较方便，因为全都是文本可打印字符。）
GIF89a
do_something();
?>
如果是其他类型的二进制文件，也有响应的头字节，如下表
格式
文件头
TIFF (tif)
49492A00
Windows Bitmap (bmp)
424D
CAD (dwg)
41433130
Adobe Photoshop (psd)
38425053
Rich Text Format (rtf)
7B5C727466
MS Word/Excel (xls.or.doc)
D0CF11E0
MS Access (mdb)
5374616E64617264204A
ZIP Archive (zip)，
504B0304
RAR Archive (rar)，
7221
Wave (wav)，
57415645
AVI (avi)，
41564920
Real Media (rm)，
2E524D46
MPEG (mpg)，
000001BA
MPEG (mpg)，
000001B3
Quicktime (mov)，
6D6F6F76
Adobe Acrobat (pdf)，
255044462D312E
Windows Media (asf)，
3026B2758E66CF11
MIDI (mid)，
4D546864
5.限制Web Server对于特定类型文件的行为
导致文件上传漏洞的根本原因在于服务把用户上传的本应是数据的内容当作了代码，一般来说，用户上传的内容都会被存储到特定的一个文件夹下，比如我们很多人习惯于放在 ./upload/ 下面要防止数据被当作代码执行，我们可以限制web server对于特定文件夹的行为。
大多数服务端软件都可以支持用户对于特定类型文件的行为的自定义，以Apache为例：
在默认情况下，对与 .php文件Apache会当作代码来执行，对于 html,css,js文件，则会直接由HTTP Response交给客户端程序对于一些资源文件，比如txt，doc，rar等等，则也会以文件下载的方式传送的客户端。我们希望用户上传的东西仅仅当作资源和数据而不能当作代码
因此可以使用服务器程序的接口来进行限制
以Apache为例,我们可以利用 .htaccess 文件机制来对web server行为进行限制
在这里插一句，如果不是专门的文件下载目录，请务必关掉文件夹浏览的权限，以防止嗅探和可能的越权，也是使用.htaccess文件，在其中加上一句
Options All -Indexes
即可。
禁止脚本执行有多种方式可以实现，而且分别有不同的效果，我们分别来看一下
1.指定特定扩展名的文件的处理方式,原理是指定Response的Content-Type可以加上如下几行
AddType text/plain .pl .py .php
这种情况下，以上几种脚本文件会被当作纯文本来显示出来，你也可以换成其他的Content-Type
2.如果要完全禁止特定扩展名的文件被访问，用下面的几行
Options -ExecCGI
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi识别
在这种情况下，以上几种类型的文件被访问的时候，会返回403 Forbidden的错误
3.也可以强制web服务器对于特定文件类型的处理，与第一条不同的是， 下面的方法直接强行让apache将文件识别为你指定的类型，而第一种是让浏览器
ForceType text/plain
看代码就可以很明白的知道，符合上面正则的全部被认为是纯文本，也可以继续往里面加入其他类型。
4.只允许访问特定类型的文件
order deny,allow
deny from all
在一个上传图片的文件夹下面，就可以加上这段代码，使得该文件夹里面只有图片扩展名的文件才可以被访问，其他类型都是拒绝访问。
这又是一个白名单的处理方案
永远记得，白名单是最有保障的安全措施
可以通过 move_uploaded_file 函数把自己写的.htaccess 文件上传，覆盖掉服务器上的文件，来定义文件类型和执行权限如果做到了这一点，将获得相当大的权限。
⑵ nginx+php fastcgi安全漏洞 在哪加if判断
加在location ~ \.php$之前就可以了，不过建议你最好升级nginx来避免解析漏洞。
⑶ 如何正确配置Nginx + PHP
对很多人而言，配置Nginx+PHP无外乎就是搜索一篇教程，然后拷贝粘贴。听上去似乎也没什么问题，可惜实际上网络上很多资料本身年久失修，漏洞百出，如果大家不求甚解，一味的拷贝粘贴，早晚有一天会为此付出代价。
假设我们用PHP实现了一个前端控制器，或者直白点说就是统一入口：把PHP请求都发送到同一个文件上，然后在此文件里通过解析“REQUEST_URI”实现路由。
此时很多教程会教大家这样配置Nginx+PHP：
server {
listen 80;
server_name foo.com;
root /path;
location / {
index index.html index.htm index.php;
if (!-e $request_filename) {
rewrite . /index.php last;
}
}
location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
这里面有很多错误，或者说至少是坏味道的地方，大家看看能发现几个。
…
我们有必要先了解一下Nginx配置文件里指令的继承关系：Nginx配置文件分为好多块，常见的从外到内依次是“http”、“server”、“location”等等，缺省的继承关系是从外到内，也就是说内层块会自动获取外层块的值作为缺省值(有例外，详见参考)。
参考：UNDERSTANDING THE NGINX CONFIGURATION INHERITANCE MODEL
…
让我们先从“index”指令入手吧，在问题配置中它是在“location”中定义的：
location / {
index index.html index.htm index.php;
}
一旦未来需要加入新的“location”，必然会出现重复定义的“index”指令，这是因为多个“location”是平级的关系，不存在继承，此时应该在“server”里定义“index”，借助继承关系，“index”指令在所有的“location”中都能生效。
参考：Nginx Pitfalls
…
接下来看看“if”指令，说它是大家误解最深的Nginx指令毫不为过：
if (!-e $request_filename) {
rewrite . /index.php last;
}
很多人喜欢用“if”指令做一系列的检查，不过这实际上是“try_files”指令的职责：
try_files $uri $uri/ /index.php;
除此以外，初学者往往会认为“if”指令是内核级的指令，但是实际上它是rewrite模块的一部分，加上Nginx配置实际上是声明式的，而非过程式的，所以当其和非rewrite模块的指令混用时，结果可能会非你所愿。
参考：IfIsEvil and How nginx “location if” works
…
下面看看“fastcgi_params”配置文件：
include fastcgi_params;
Nginx有两份fastcgi配置文件，分别是“fastcgi_params”和“fastcgi.conf”，它们没有太大的差异，唯一的区别是后者比前者多了一行“SCRIPT_FILENAME”的定义：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
注意：$document_root 和 $fastcgi_script_name 之间没有 /。
原本Nginx只有“fastcgi_params”，后来发现很多人在定义“SCRIPT_FILENAME”时使用了硬编码的方式，于是为了规范用法便引入了“fastcgi.conf”。
不过这样的话就产生一个疑问：为什么一定要引入一个新的配置文件，而不是修改旧的配置文件?这是因为“fastcgi_param”指令是数组型的，和普通指令相同的是：内层替换外层;和普通指令不同的是：当在同级多次使用的时候，是新增而不是替换。换句话说，如果在同级定义两次“SCRIPT_FILENAME”，那么它们都会被发送到后端，这可能会导致一些潜在的问题，为了避免此类情况，便引入了一个新的配置文件。
参考：FASTCGI_PARAMS VERSUS FASTCGI.CONF – NGINX CONFIG HISTORY
此外，我们还需要考虑一个安全问题：在PHP开启“cgi.fix_pathinfo”的情况下，PHP可能会把错误的文件类型当作PHP文件来解析。如果Nginx和PHP安装在同一台服务器上的话，那么最简单的解决方法是用“try_files”指令做一次过滤：
try_files $uri =404;
参考：Nginx文件类型错误解析漏洞
…
依照前面的分析，给出一份改良后的版本，是不是比开始的版本清爽了很多：
server {
listen 80
server_name foo.com;
root /path;
index index.html index.htm index.php;
location / {
try_files $uri $uri/ /index.php;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
}
}
实际上还有一些瑕疵，主要是“try_files”和“fastcgi_split_path_info”不够兼容，虽然能够解决，但方案比较丑陋，具体就不多说了，有兴趣的可以参考问题描述。
补充：因为“location”已经做了限定，所以“fastcgi_index”其实也没有必要.
⑷ nginx 只让php入口文件访问，其他php文件禁止直接访问
你用的系统是微擎吗？
正常来说，除了这两个php文件，和回调用的接口外，其它php都是不能直接访问的，文件头有常量判断，未定义就退出了。
所以你的系统有上传漏洞，应该检查是哪里出了问题，并去修复一下。可以从以下几点着手：
上传权限仅提供给已登录会员，在上传接口中判断未登录状态的，直接返回错误信息
上传文件类型限制，如果需要的是图片，严格限制图片类型，并做图片规格检测（gd库就可以处理），不符合的不保存文件
文件名处理，不要使用客户端上传的文件名保存，而是根据规则 生成一个随机的名字保存
上传频率限制（根据会员限制），比如，一个小时内限制上传5张，一天限制100张，可以有效防止黑客利用上传接口填充垃圾文件到你的服务器
如果可行，对上传文件做一个临时机制，如上传的文件先放到临时文件夹，资料保存的时候，把文件处理一下，移动到正常的附件目录。这样就可以定期清理临时文件夹，防止上传后没使用的文件过多占用服务器空间。
不过这个功能改起来会复杂一点，要处理所有使用到上传功能的接口。
以上几点处理好，被上传可执行文件的问题基本上可以杜绝了
而你的解决方案，是只治标不治本的方案