PHP里8个鲜为人知的PHP安全函数

安全函数在php中起到了很大的作用可以简单的帮助我们过滤一些非常的sql注入了，下文小编为各位整理一下。

安全是编程非常重要的一个方面。在任何一种编程语言中，都提供了许多的函数或者模块来确保程序的安全性。在现代网站应用中，经常要获取来自世界各地用户的输入，但是，我们都知道“永远不能相信那些用户输入的数据”。所以在各种的Web开发语言中，都会提供保证用户输入数据安全的函数。今天，我们就来看看，在著名的开源语言PHP中有哪些有用的安全函数。

在PHP中，有些很有用的函数开源非常方便的防止你的网站遭受各种攻击，例如SQL注入攻击，XSS（Cross Site Scripting：跨站脚本）攻击等。一起看看PHP中常用的、可以确保项目安全的函数。注意，这并不是完整的列表，是我觉得对于你的i项目很有的一些函数。

1. mysql_real_escape_string()

这个函数在PHP中防止SQL注入攻击时非常有用。这个函数会对一些例如单引号、双引号、反斜杠等特殊字符添加一个反斜杠以确保在查询这些数据之前，用户提供的输入是干净的。但要注意，你是在连接数据库的前提下使用这个函数。

但是现在已经不推荐使用mysql_real_escape_string()了，所有新的应用应该使用像PDO一样的函数库执行数据库操作，也就是说，我们可以使用现成的语句防止SQL注入攻击。

2. addslashes()

这个函数的原理跟mysql_real_escape_string()相似。但是当在php.ini文件中，“magic_quotes_gpc“的值是“on”的时候，就不要使用这个函数。magic_quotes_gpc 的默认值是on，对所有的 GET、POST 和 COOKIE 数据自动运行 addslashes()。不要对已经被 magic_quotes_gpc 转义过的字符串使用 addslashes()，因为这样会导致双层转义。你可以使用get_magic_quotes_gpc()函数来确定它是否开启。

3. htmlentities()

这个函数对于过滤用户输入的数据非常有用。它会将一些特殊字符转换为HTML实体。例如，用户输入<时，就会被该函数转化为HTML实体<（&lt），输入>就被转为实体&gt.

4. htmlspecialchars()

在HTML中，一些特定字符有特殊的含义，如果要保持字符原来的含义，就应该转换为HTML实体。这个函数会返回转换后的字符串，例如‘&’ (ampersand) 转为’&amp‘（ps:请参照第三点中的实体对照表链接）

ps:此处原文有误（见评论），在此非常感谢瑾瑜  提出。现已更正，另外附上此函数常见的转换字符：

The translations performed are:

 ‘&’ (ampersand) becomes ‘&amp;’
 ‘”‘ (double quote) becomes ‘&quot;’ when ENT_NOQUOTES is not set.
 “‘” (single quote) becomes ‘&#039;’ (or &apos;) only when ENT_QUOTES is set.
 ‘<’ (less than) becomes ‘&lt;’
 ‘>’ (greater than) becomes ‘&gt;’
5. strip_tags()

这个函数可以去除字符串中所有的HTML，JavaScript和PHP标签，当然你也可以通过设置该函数的第二个参数，让一些特定的标签出现。

6. md5()

从安全的角度来说，一些开发者在数据库中存储简单的密码的行为并不值得推荐。md5()函数可以产生给定字符串的32个字符的md5散列，而且这个过程不可逆，即你不能从md5()的结果得到原始字符串。

现在这个函数并不被认为是安全的，因为开源的数据库可以反向检查一个散列值的明文。你可以在这里找到一个MD5散列数据库列表

7. sha1()

这个函数与md5()类似，但是它使用了不同的算法来产生40个字符的SHA-1散列（md5产生的是32个字符的散列）。也不要把绝对安全寄托在这个函数上，否则会有意想不到的结果。

8. intval()

先别笑，我知道这个函数和安全没什么关系。intval()函数是将变量转成整数类型，你可以用这个函数让你的PHP代码更安全，特别是当你在解析id，年龄这样的数据时。

CSRF（Cross-site request forgery跨站请求伪造，也被称为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性

 

CSRF是什么？

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

 

CSRF可以做什么？

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

 

CSRF漏洞现状

CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

 

CSRF的原理

下图简单阐述了CSRF攻击的思想：

csrfyl

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
上面大概地讲了一下CSRF攻击的思想，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻:>）

 

示例

示例1

银行网站A，它以GET请求来完成银行转账的操作，如：http://www.111cn.net /Transfer.php?toBankId=11&money=1000

危险网站B，它里面有一段HTML的代码如下：

XHTML

<img src=http://www.111cn.net /Transfer.php?toBankId=11&money=1000>

首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的<img>以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.111cn.net /Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......

 

示例2

为了杜绝上面的问题，银行决定改用POST请求完成转账操作。

银行网站A的WEB表单如下：

XHTML

<form action="Transfer.php" method="POST">
    <p>ToBankId: <input type="text" name="toBankId" /></p>
    <p>Money: <input type="text" name="money" /></p>
    <p><input type="submit" value="Transfer" /></p>
</form>
后台处理页面Transfer.php如下：

PHP

<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　    buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
?>
危险网站B，仍然只是包含那句HTML代码：

XHTML

<img src=http://www.111cn.net /Transfer.php?toBankId=11&money=1000>

和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

 
示例3

经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　    buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
?>
然而，危险网站B与时俱进，它改了一下代码：
<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>
 
　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.111cn.net /Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>
如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个<img>就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。

理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

 

CSRF的防御

我总结了一下看到的资料，CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。

 

服务端进行CSRF防御

服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数或检测访问来路是否可信。

 

Cookie Hashing(所有表单都包含同一个伪随机值)

第一个方案可能是解决这个问题的最简单和快捷的方案了，因为攻击者不能够获得被攻击者的Cookies内容，也就不能够构造相应的表单。

<?php
　　　　//构造加密的Cookie信息
　　　　$value = "DefenseSCRF";
　　　　setcookie("cookie", $value, time()+3600);
?>
在表单里增加Hash值，以认证这确实是用户发送的请求。

<?php
　　　　$hash = md5($_COOKIE['cookie']);
?>
<form method=”POST” action=”transfer.php”>
　　　　<input type=”text” name=”toBankId”>
　　　　<input type=”text” name=”money”>
　　　　<input type=”hidden” name=”hash” value=”<?=$hash;?>”>
　　　　<input type=”submit” name=”submit” value=”Submit”>
</form>

然后在服务器端进行Hash值验证

<?php
　　      if(isset($_POST['check'])) {
     　　      $hash = md5($_COOKIE['cookie']);
          　　 if($_POST['check'] == $hash) {
               　　 doJob();
　　           } else {
　　　　　　　　//...
          　　 }
　　      } else {
　　　　　　//...
　　      }
?>
事实上，如果我们不考虑用户的Cookies很容易由于网站中存在XSS漏洞而被偷窃（我们已经知道这样的事情并不少见）这一事实，这是一个很好的应对对CSRF的解决方案。如果我们为用户的每一个表单请求中都加入随机的Cookies，那么这种方法会变得更加安全，但是这并不是十分合适。

 
HTTP来路

检测访问来路是否可信的最简单方法是，获得HTTP请求中的来路信息（即名为Referer的HTTP头）并且检查它来自站内还是来自一个远程的恶意页面：这是一个很好的解决方法，但是由于可以对服务器获得的请求来路进行欺骗以使得他们看起来合法，但这种方法不能够有效防止攻击。

让我们来看看为什么这并不是一个合适的方法。下面的代码展示了HTTP Referer实现方法的一个例子：

check.php

if(eregi("www.111cn.net", $_SERVER['HTTP_REFERER'])) {
    do_something();
} else {
    echo "Malicious Request!";
}
这个检测则会轻易的忽略掉来自某个攻击者伪造的HTTP Referer欺骗，攻击者可以使用如下代码：

header("Referer: www.111cn.net");

或者其他在恶意脚本中伪造HTTP头并发送的方法。

由于HTTP Referer是由客户端浏览器发送的，而不是由服务器控制的，因此你不应当将该变量作为一个信任源。

 

验证码

另外一个解决这类问题的思路则是在用户提交的每一个表单中使用一个随机验证码，让用户在文本框中填写图片上的随机字符串，并且在提交表单后对其进行检测。

这个方法曾经在之前被人们放弃，这是由于验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

你可以在Secunia的站点上获得关于此缺陷的详细信息：http://secunia.com/advisories/19738/ 。

这里是Secunia关于此Bug解释的概述：

“此缺陷是由于处理“mhtml:”的URL处理器重定向引起的。它可以被用来利用从另外一个网站访问当前的文档”

事实上，我们知道，这个Bug已经被微软放出的Windows XP和Windows Vista及其浏览器IE6.0的修复包所解决了。即使他的确出现了安全问题，这么长时间也会有其他的可靠方案出现。

 
一次性令牌

现在让我们来看经过研究，我希望介绍的最后一种解决方案：在使用这些不可靠的技术后，我尝试做一些不同然而却是更有效的方法。

为了防止Web表单受到Session欺骗（CSRF）的攻击，我决定检测可能被伪装或伪造的每一个项目。因此我需要来创造一次性令牌，来使得在任何情况下都不能够被猜测或者伪装，这些一次性令牌在完成他们的工作后将被销毁。

让我们从令牌值的生成开始：

functions.php

function gen_token() {
     // uniqid()根据当前的时间（毫秒数）获得一个唯一的ID，这个唯一ID有利于生成一个不重复的数值
     $hash = md5(uniqid(rand(), true));
 
     // 得到相应ID值的MD5散列，而后我们从该散列中以一个小于24的数字为开始位置，选取8位字母
     $n = rand(1, 24);
     $token = substr($hash, $n, 8);
 
     return $token;
}
现在让我们生成一个Session令牌，在稍后的检查中我们会用到它。

functions.php

function gen_stoken() {
     // Call the function to generate the token
     $token = gen_token();
     // Destroy any eventually Session Token variable
     destroy_stoken();
     // Create the Session Token variable
     session_register(STOKEN_NAME);
     $_SESSION[STOKEN_NAME] = $token;
}
在这个函数中我们调用gen_token()函数，并且使用返回的令牌将其值复制到一个新的$_SESSION变量。

现在让我们来看启动完整机制中为我们的表单生成隐藏输入域的函数：

functions.php

function gen_input() {
     // Call the function to generate the Session Token variable
     gen_stoken();
     // Generate the form input code
     echo '<input type="hidden” name=”' . FTOKEN_NAME . '” value=”' . $_SESSION['STOKEN_NAME'] . '">';
}
我们可以看到，这个函数调用了gen_stoken()函数并且生成在WEB表单中包含隐藏域的HTML代码。

接下来让我们来看实现对隐藏域中提交的Session令牌的检测的函数：

functions.php

function token_check() {
     // Check if the Session Token exists
     if (is_stoken()) {
          // Check if the request has been sent
          if(isset($_REQUEST[FTOKEN_NAME])) {
               // If the Form Token is different from Session Token
               // it’s a malicious request
               if($_REQUEST[FTOKEN_NAME] != $_SESSION[STOKEN_NAME]) {
                    gen_error(1);
                    destroy_stoken();
                    exit();
               } else {
                    destroy_stoken();
               }
          // If it isn’t then it’s a malicious request
          } else {
               gen_error(2);
               destroy_stoken();
               exit();
          }
     // If it isn’t then it’s a malicious request
     } else {
          gen_error(3);
          destroy_stoken();
          exit();
     }
}
这个函数检测了$_SESSION[STOKEN_NAME]和$_REQUEST[FTOKEN_NAME]的存在性（我使用了$_REQUEST方法来使得GET和POST两种方式提交的表单变量均能够被接受），而后检测他们的值是否相同，因此判断当前表单提交是否是经过认证授权的。

这个函数的重点在于：在每次检测步骤结束后，令牌都会被销毁，并且仅仅在下一次表单页面时才会重新生成。

这些函数的使用方法非常简单，我们只需要加入一些PHP代码结构。

下面是Web表单：

form.php

<?php
     session_start();
     include("functions.php");
?>
<form method="POST" action="resolve.php">
     <input type="text" name="first_name">
     <input type="text" name="last_name">
     <!– Call the function to generate the hidden input –>
     <? gen_input(); ?>
     <input type="submit" name="submit" value="Submit">
</form>
下面是resolve.php的脚本代码：

resolve.php

<?php
session_start();
include("functions.php");
 
// Call the function to make the check
token_check();
 
// Your code
你可以看到，实现这样一个检测是十分简单的，但是它可以避免你的用户表单被攻击者劫持，以避免数据被非法授权。

 

总结

现在你的Web应用程序没有百分百的安全，但是你可以开始避免绝大多数普通的攻击技术。

我希望您关注的另一个要点是，Web开发者不应当忽视一般的程序错误（例如XSS 浏览器漏洞等等），不将这些考虑为对您的用户的潜在威胁是一个巨大的错误：你应该永远记得它们将影响程序的信任性、安全性和互操作性

我们做的简单评论功能会发现有提交很多的html标签了这些标签会导致页面有一些外连了，下面我们一起来看在Php中过滤表单提交的html标签方法。

近评论中有一些机器人提交的post链接，都是一些垃圾评论。为了减少这种无谓的链接内容出现，其实是可以用php来删除表单POST提交的html标签，这样机器提交的信息也不会得到他们要的结果。而且可以减少来自seo/seo.html" target="_blank">搜索引擎的惩罚。

去掉<br/>标签

某些情况我们需要去掉<br/>标签，可以使用str_replace函数。

//取出br标记

代码如下	复制代码
$str=str_replace("<br>","",$str);

移除html标签

可以使用strip_tags函数搞定。

代码如下	复制代码
$str= strip_tags($str);

封装成一个函数

代码如下	复制代码
<?php     function removehtml($str){         $str=str_replace("<br>","",$str);         return strip_tags($str);     } ?>

PHP DDOS是一种利用php写的一款向外部服务器发布数据的一段代码了，几年前自己服务器中过一次php ddos了，phpddos主要作用是黑客利用服务器本身的php环境，然后把代码上传服务器上，再利用外部工具来控制这段代码的执行与攻击外部的那台机器，从而让你机器资源耗尽了，下面我们来看360杀毒PHP-DDOS脚本专杀工具怎么安装使用吧

1、百度搜索 360PHP-DDOS脚本专杀工具 我们进入到360官方去下载这个工具包。

2、下载好工具包之后我们再把 360doskill.php 上传到你的网站根目录了。

3、 然后我们再直接在浏览器输访问360doskill.php，访问地址：http://网站域名/360doskill.php

4、然后我们输入默认的用户名与密码登录。

5、然后我们点击扫描就可以扫描整个目录了，当然也可以指定目录搜索php ddos代码了。

6、如扫描之后会发现所有的php ddos文件所在目录我们只要远程上服务器删除即可。

友情提示，我们的最好对360doskill.php 文件的默认用户名与密码进行修改哦。

CC攻击攻击的原因就是不停的刷新动态页面如php+mysql读写数据库的页面，这样如果刷新比较快可以导致页面卡死或服务器资源使用超量，从而导致服务器挂了，下面给大家整理了一些防止CC攻击的例子。

CC攻击原因

CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来攻击页面的，每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，CC就是模拟多个用户（多少线程就是多少用户）不停地进行访问那些需要大量数据操作（就是需要大量CPU时间）的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。

cc攻击刷新页面对我们没有任何意义，要说有意义就是把我们的网站资源使用尽了。

防御CC攻击可以通过多种方法，禁止网站代理访问，尽量将网站做成静态页面，限制连接数量，修改最大超时时间等。

例子

代码如下

复制代码

<?php //代理IP直接退出 empty($_SERVER['HTTP_VIA']) or exit('Access Denied'); //防止快速刷新 session_start(); $seconds = '3'; //时间段[秒] $refresh = '5'; //刷新次数 //设置监控变量 $cur_time = time(); if(isset($_SESSION['last_time'])){  $_SESSION['refresh_times'] += 1; }else{  $_SESSION['refresh_times'] = 1;  $_SESSION['last_time'] = $cur_time; } //处理监控结果 if($cur_time - $_SESSION['last_time'] < $seconds){  if($_SESSION['refresh_times'] >= $refresh){   //跳转至攻击者服务器地址   header(sprintf('Location:%s', 'http://127.0.0.1'));   exit('Access Denied');  } }else{  $_SESSION['refresh_times'] = 0;  $_SESSION['last_time'] = $cur_time; } ?>

防火墙是防CC攻击一个非常不错的解决方案了，不但不会对服务器有任何影响同时能有效的防止CC攻击

推荐小站长可使用安全狗来做防CC攻击或使用linux iptalbs来防止CC攻击，同样像我的服务器有机房防火墙会自动拦截这些类型的攻击哦。