精华内容
下载资源
问答
  • SQL注入:用户利用在表单字段输入SQL语句的方式来影响正常的SQL执行。防止:使用mysql_real_escape_string()过滤数据手动检查每一数据是否为正确的...XSS攻击:跨站点脚本攻击,由用户输入一些数据到你的网站,其...

    a9fbca94c65d6f057e0603eff8866424.png

    SQL注入:用户利用在表单字段输入SQL语句的方式来影响正常的SQL执行。

    防止:

    使用mysql_real_escape_string()过滤数据

    手动检查每一数据是否为正确的数据类型

    使用预处理语句并绑定变量

    参数化SQL:是指在设计与数据库链接并访问数据时,在需要填入数值或数据的地方,使用参数(Parameter)来给值,用@或?来表示参数。

    XSS攻击:跨站点脚本攻击,由用户输入一些数据到你的网站,其中包括客户端脚本(通常JavaScript)。如果你没有过滤就输出数据到另一个web页面,这个脚本将被执行。

    防止:为了防止XSS攻击,使用PHP的htmlentities()函数过滤再输出到浏览器。

    CSRF:跨站点请求伪造,是指一个页面发出的请求,看起来就像是网站的信任用户,但是是伪造的

    防止:一般来说,确保用户来自你的表单,并且匹配每一个你发送出去的表单。有两点一定要记住:

    对用户会话采用适当的安全措施,例如:给每一个会话更新id和用户使用SSL。

    生成另一个一次性的令牌并将其嵌入表单,保存在会话中(一个会话变量),在提交时检查它。如laravel中的_token

    代码注入:代码注入是利用计算机漏洞通过处理无效数据造成的。问题出在,当你不小心执行任意代码,通常通过文件包含。写得很糟糕的代码可以允许一个远程文件包含并执行。如许多PHP函数,如require可以包含URL或文件名。

    防止代码注入

    过滤用户输入

    在php.ini中设置禁用allow_url_fopen和allow_url_include。这将禁用require/include/fopen的远程文件

    好了,以上就是今天合肥达内分享的全部内容,希望对你有所帮助。

    展开全文
  • php安全性漫谈

    2021-05-06 01:53:38
    原文出处:应该为程序的每个方面创建不同的数据库帐号,并...2.数据库连接问题把连接建立在 SSL 加密技术上可以增加客户端和服务器端通信的安全性,或者 SSH 也可以用于加密客户端和数据库之间的连接。如果使用了这...

    原文出处:

    7e1ced6c523a434c8d9d3542d72f417c.png

    d548352eb4deb6de9851e638a4beab3d.png

    应该为程序的每个方面创建不同的数据库帐号,并赋予对数据库对象的极有限的权限。仅分配给能完成其功能所需的权限,避免同一个用户可以完成另一个用户的事情。这样即使攻击者利用程序漏洞取得了数据库的访问权限,也最多只能做到和该程序一样的影响范围。

    2.数据库连接问题

    把连接建立在 SSL 加密技术上可以增加客户端和服务器端通信的安全性,或者 SSH 也可以用于加密客户端和数据库之间的连接。如果使用了这些技术的话,攻击者要监视服务器的通信或者得到数据库的信息是很困难的。

    3.数据库数据的加密

    SSL/SSH 能保护客户端和服务器端交换的数据,但 SSL/SSH 并不能保护数据库中已有的数据。SSL 只是一个加密网络数据流的协议。

    如果攻击者取得了直接访问数据库的许可(绕过 web 服务器),敏感数据就可能暴露或者被滥用,除非数据库自己保护了这些信息。对数据库内的数据加密是减少这类风险的有效途径,但是只有很少的数据库提供这些加密功能。

    对于这个问题,有一个简单的解决办法,就是创建自己的加密机制,然后把它用在 PHP 程序内,最常见的例子就是把密码经过 MD5 加密后的散列存进数据库来代替原来的明文密码。

    $query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",

    addslashes($username), md5($password));

    $result = pg_query($connection, $query);

    $query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",

    addslashes($username), md5($password));

    $result = pg_query($connection, $query);

    if (pg_num_rows($result) > 0) {

    echo 'Welcome, $username!';

    } else {

    echo 'Authentication failed for $username.';

    }

    ?>

    4、SQL注入问题

    直接 SQL 命令注入就是攻击者常用的一种创建或修改已有 SQL 语句的技术,从而达到取得隐藏数据,或覆盖关键的值,甚至执行数据库主机操作系统命令的目的。这是通过应用程序取得用户输入并与静态参数组合成 SQL 查询来实现的。下面将会给出一些真实的例子。

    $query = "SELECT id, name, inserted, size FROM products

    WHERE size = '$size'

    ORDER BY $order LIMIT $limit, $offset;";

    $result = odbc_exec($conn, $query);

    ?>

    可以在原来的查询的基础上添加另一个 SELECT 查询来获得密码: union select ’1′, concat(uname||’-'||passwd) as name, ’1971-01-01′, ’0′ from usertable; 假如上述语句(使用 ‘ 和 –)被加入到 $query 中的任意一个变量的话,那么就麻烦了。

    这些攻击总是建立在发掘安全意识不强的代码上的。所以,永远不要信任外界输入的数据,特别是来自于客户端的,包括选择框、表单隐藏域和 cookie。就如上面的第一个例子那样,就算是正常的查询也有可能造成灾难。

    永远不要使用超级用户或所有者帐号去连接数据库。要用权限被严格限制的帐号。 检查输入的数据是否具有所期望的数据格式。PHP 有很多可以用于检查输入的函数,从简单的变量函数和字符类型函数(比如 is_numeric(),ctype_digit())到复杂的 Perl 兼容正则表达式函数都可以完成这个工作。

    如果程序等待输入一个数字,可以考虑使用 is_numeric() 来检查,或者直接使用 settype() 来转换它的类型,也可以用 sprintf() 把它格式化为数字。

    一个更安全的防止SQL注入的分页显示方法:

    settype($offset, 'integer');

    $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";

    $query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",

    $offset);

    ?>

    展开全文
  • 攻击类型 目录 1. Xss 跨站脚本攻击 1.1. 什么是xss 1.1.1.存储型 XSS ...​​​​​​​1.2.XSS 攻击的预防 ...1.2.1. 预防存储型和反射型 XSS 攻击 ...常见的CSRF攻击 ​​​​​​​2.3.防护策略 ...

    攻击类型

    目录

    1.  Xss 跨站脚本攻击

    1.1. 什么是xss

    1.1.1. 存储型 XSS

    1.1.2. 反射型 XSS

    1.1.3. DOM 型 XSS

    1.2. XSS 攻击的预防

    1.2.1. 预防存储型和反射型 XSS 攻击

    1.2.2. 预防 DOM 型 XSS 攻击

    2. ​​​​​​​CSRF 跨站请求伪造

    2.1. 什么是跨站请求伪造

    ​​​​​​​2.2. 常见的CSRF攻击

    ​​​​​​​2.3. 防护策略

    3. ClickJacking(点击劫持)

    3.1. 什么是点击劫持

    ​​​​​​​3.2. 如何防御

    4. 文件上传漏洞

    4.1. 什么是文件上传漏洞

    ​​​​​​​4.2. 常见防御措施

    ​​​​​​​5. 不安全的第三方依赖包

    ​​​​​​​5.1 Npm漏洞防御措施


    ​​​​​​​

    1.  Xss 跨站脚本攻击

    1.1. 什么是xss

    Cross-Site Scripting(跨站脚本攻击)简称 XSS,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使之在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如 Cookie、SessionID 等,进而危害数据安全。

    为了和 CSS 区分,这里把攻击的第一个字母改成了 X,于是叫做 XSS。

    XSS 的本质是:恶意代码未经过滤,与网站正常的代码混在一起;浏览器无法分辨哪些脚本是可信的,导致恶意脚本被执行。

    而由于直接在用户的终端执行,恶意代码能够直接获取用户的信息,或者利用这些信息冒充用户向网站发起攻击者定义的请求。

    在部分情况下,由于输入的限制,注入的恶意脚本比较短。但可以通过引入外部的脚本,并由浏览器执行,来完成比较复杂的攻击策略。

    Xss 分类

    根据攻击的来源,XSS 攻击可分为存储型、反射型和 DOM 型三种。

    类型

    存储区*

    插入点*

    存储型 XSS

    后端数据库

    HTML

    反射型 XSS

    URL

    HTML

    DOM 型 XSS

    后端数据库/前端存储/URL

    前端 JavaScript

    存储区:恶意代码存放的位置。

    插入点:由谁取得恶意代码,并插入到网页上。

    1.1.1. 存储型 XSS

    存储型 XSS 的攻击步骤:

    1. 攻击者将恶意代码提交到目标网站的数据库中。
    2. 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

    这种攻击常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等。

    1.1.2. 反射型 XSS

    反射型 XSS 的攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。
    2. 用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

    反射型 XSS 跟存储型 XSS 的区别是:存储型 XSS 的恶意代码存在数据库里,反射型 XSS 的恶意代码存在 URL 里。

    反射型 XSS 漏洞常见于通过 URL 传递参数的功能,如网站搜索、跳转等。

    由于需要用户主动打开恶意的 URL 才能生效,攻击者往往会结合多种手段诱导用户点击。

    POST 的内容也可以触发反射型 XSS,只不过其触发条件比较苛刻(需要构造表单提交页面,并引导用户点击),所以非常少见。

    ​​​​​​​1.1.3. DOM 型 XSS

    DOM 型 XSS 的攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。
    2. 用户打开带有恶意代码的 URL。
    3. 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

    DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。

    ​​​​​​​1.2. XSS 攻击的预防

    通过前面的介绍可以得知,XSS 攻击有两大要素:

    1. 攻击者提交恶意代码。
    2. 浏览器执行恶意代码。

    针对第一个要素:我们是否能够在用户输入的过程,过滤掉用户输入的恶意代码呢?

    输入过滤

    在用户提交时,由前端过滤输入,然后提交到后端。这样做是否可行呢?

    答案是不可行。一旦攻击者绕过前端过滤,直接构造请求,就可以提交恶意代码了。

    那么,换一个过滤时机:后端在写入数据库前,对输入进行过滤,然后把“安全的”内容,返回给前端。这样是否可行呢?

    我们举一个例子,一个正常的用户输入了 5 < 7 这个内容,在写入数据库前,被转义,变成了 5 &lt; 7

    问题是:在提交阶段,我们并不确定内容要输出到哪里。

    这里的“并不确定内容要输出到哪里”有两层含义:

    1. 用户的输入内容可能同时提供给前端和客户端,而一旦经过了 escapeHTML(),客户端显示的内容就变成了乱码( 5 &lt; 7 )
    2. 在前端中,不同的位置所需的编码也不同。

    当 5 &lt; 7 作为 HTML 拼接页面时,可以正常显示:

    <div title="comment">5 &lt; 7</div>

    当 5 &lt; 7 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示,也不能直接用于内容长度计算。不能用于标题、alert 等

    所以,输入侧过滤能够在某些情况下解决特定的 XSS 问题,但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。

    当然,对于明确的输入类型,例如数字、URL、电话号码、邮件地址等等内容,进行输入过滤还是必要的。

    既然输入过滤并非完全可靠,我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类:

    • 防止 HTML 中出现注入。
    • 防止 JavaScript 执行时,执行恶意代码。

    1.2.1. 预防存储型和反射型 XSS 攻击

    存储型和反射型 XSS 都是在服务端取出恶意代码后,插入到响应 HTML 里的,攻击者刻意编写的“数据”被内嵌到“代码”中,被浏览器所执行。

    预防这两种漏洞,有两种常见做法:

    • 改成纯前端渲染,把代码和数据分隔开。
    • 对 HTML 做充分转义。

    纯前端渲染

    纯前端渲染的过程:

    1. 浏览器先加载一个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。
    2. 然后浏览器执行 HTML 中的 JavaScript。
    3. JavaScript 通过 Ajax 加载业务数据,调用 DOM API 更新到页面上。

    在纯前端渲染中,我们会明确的告诉浏览器:下面要设置的内容是文本(.innerText),还是属性(.setAttribute),还是样式(.style)等等。浏览器不会被轻易的被欺骗,执行预期外的代码了。

    但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload 事件和 href 中的 javascript:xxx等,请参考下文”预防 DOM 型 XSS 攻击“部分)。

    在很多内部、管理系统中,采用纯前端渲染是非常合适的。但对于性能要求高,或有 SEO 需求的页面,我们仍然要面对拼接 HTML 的问题。

    转义 HTML

    如果拼接 HTML 是必要的,就需要采用合适的转义库,对 HTML 模板各处插入点进行充分的转义。

    常用的模板引擎,如 doT.js、ejs、FreeMarker 等,对于 HTML 转义通常只有一个规则,就是把 & < > " ' / 这几个字符转义掉,确实能起到一定的 XSS 防护作用,但并不完善:

    XSS 安全漏洞

    简单转义是否有防护作用

    HTML 标签文字内容

    HTML 属性值

    CSS 内联样式

    内联 JavaScript

    内联 JSON

    跳转链接

    所以要完善 XSS 防护措施,我们要使用更完善更细致的转义策略。

    ​​​​​​​1.2.2. 预防 DOM 型 XSS 攻击

    DOM 型 XSS 攻击,实际上就是网站前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执行了。

    在使用 .innerHTML.outerHTMLdocument.write() 时要特别小心,不要把不可信的数据作为 HTML 插到页面上,而应尽量使用 .textContent.setAttribute() 等。

    如果用 Vue/React 技术栈,并且不使用 v-html/dangerouslySetInnerHTML 功能,就在前端 render 阶段避免 innerHTMLouterHTML 的 XSS 隐患。

    DOM 中的内联事件监听器,如 locationonclickonerroronloadonmouseover 等,<a> 标签的 href 属性,JavaScript 的 eval()setTimeout()setInterval() 等,都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API,很容易产生安全隐患,请务必避免。

    <!-- 内联事件监听器中包含恶意代码 -->
    <img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">
    
    <!-- 链接内包含恶意代码 -->
    <a href="UNTRUSTED">1</a>
    
    <script>
    
    // setTimeout()/setInterval() 中调用恶意代码
    setTimeout("UNTRUSTED")
    setInterval("UNTRUSTED")
    
    // location 调用恶意代码
    location.href = 'UNTRUSTED'
    
    // eval() 中调用恶意代码
    eval("UNTRUSTED")
    
    </script>

    如果项目中有用到这些的话,一定要避免在字符串中拼接不可信数据。

    输入内容长度控制

    对于不受信任的输入,都应该限定一个合理的长度。虽然无法完全防止 XSS 发生,但可以增加 XSS 攻击的难度。

    避免拼接 HTML
    前端采用拼接 HTML 的方法比较危险,如果框架允许,使用 createElementsetAttribute 之类的方法实现。或者采用比较成熟的渲染框架,如 Vue/React 等。

    时刻保持警惕
    在插入位置为 DOM 属性、链接等位置时,要打起精神,严加防范。

    增加攻击难度,降低攻击后果
    通过 CSP(Content Security Policy)、输入长度配置、接口安全措施等方法,增加攻击的难度,降低攻击的后果。

    ​​​​​​​2. ​​​​​​​CSRF 跨站请求伪造

    2.1. 什么是跨站请求伪造

    CSRF(Cross-site request forgery)跨站请求伪造:攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。

    一个典型的CSRF攻击有着如下的流程:

    • 受害者登录a.com,并保留了登录凭证(Cookie)。
    • 攻击者引诱受害者访问了b.com。
    • b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie。
    • a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求。
    • a.com以受害者的名义执行了act=xx。
    • 攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作。

    ​​​​​​​2.2. 常见的CSRF攻击

    • GET类型的CSRF

    GET类型的CSRF利用非常简单,只需要一个HTTP请求,一般会这样利用:

    <img src="http://bank.example/withdraw?amount=10000&for=hacker" > 

    在受害者访问含有这个img的页面后,浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。

    • POST类型的CSRF

    这种类型的CSRF利用起来通常使用的是一个自动提交的表单,如:

    <form action="http://bank.example/withdraw" method=POST>
        <input type="hidden" name="account" value="xiaoming" />
        <input type="hidden" name="amount" value="10000" />
        <input type="hidden" name="for" value="hacker" />
    </form>
    <script> 
        document.forms[0].submit(); 
    </script> 

    访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作。

    POST类型的攻击通常比GET要求更加严格一点,但仍并不复杂。任何个人网站、博客,被黑客上传页面的网站都有可能是发起攻击的来源,后端接口不能将安全寄托在仅允许POST上面。

    • 链接类型的CSRF

    链接类型的CSRF并不常见,比起其他两种用户打开页面就中招的情况,这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接,或者以广告的形式诱导用户中招,攻击者通常会以比较夸张的词语诱骗用户点击,例如:

    <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
        重磅消息!!
    <a/>

    由于之前用户登录了信任的网站A,并且保存登录状态,只要用户主动访问上面的这个PHP页面,则表示攻击成功。

    ​​​​​​​2.3. 防护策略

    CSRF通常从第三方网站发起,被攻击的网站无法防止攻击发生,只能通过增强自己网站针对CSRF的防护能力来提升安全性。

    上文中讲了CSRF的两个特点:

    • CSRF(通常)发生在第三方域名。
    • CSRF攻击者不能获取到Cookie等信息,只是使用。

    针对这两点,我们可以专门制定防护策略,如下:

    • 阻止不明外域的访问
      • 同源检测
      • Samesite Cookie
    • 提交时要求附加本域才能获取的信息
      • CSRF Token

    既然CSRF大多来自第三方网站,那么我们就直接禁止外域(或者不受信任的域名)对我们发起请求。

    那么问题来了,我们如何判断请求是否来自外域呢?

    在HTTP协议中,每一个异步请求都会携带两个Header,用于标记来源域名:

    • Origin Header
    • Referer Header

    这两个Header在浏览器发起请求时,大多数情况会自动带上,并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名,确定请求的来源域。

    使用Origin Header确定来源域名

    在部分与CSRF有关的请求中,请求的Header中会携带Origin字段。字段内包含请求的域名(不包含path及query)。

    如果Origin存在,那么直接使用Origin中的字段确认来源域名就可以。

    但是Origin在以下两种情况下并不存在:

    • IE11同源策略: IE 11 不会在跨站CORS请求上添加Origin标头,Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同,有两个主要的区别,可以参考MDN Same-origin_policy#IE_Exceptions
    • 302重定向: 在302重定向之后Origin不包含在重定向的请求中,因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL,因此浏览器不想将Origin泄漏到新的服务器上。

    使用Referer Header确定来源域名

    根据HTTP协议,在HTTP头中有一个字段叫Referer,记录了该HTTP请求的来源地址。 对于Ajax请求,图片和script等资源请求,Referer为发起请求的页面地址。对于页面跳转,Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。

    这种方法并非万无一失,Referer的值是由浏览器提供的,虽然HTTP协议上有明确的要求,但是每个浏览器对于Referer的具体实现可能有差别,并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法,就是把安全性都依赖于第三方(即浏览器)来保障,从理论上来讲,这样并不是很安全。在部分情况下,攻击者可以隐藏,甚至修改自己请求的Referer。

    综上所述:同源验证是一个相对简单的防范方法,能够防范绝大多数的CSRF攻击。但这并不是万无一失的,对于安全性要求较高,或者有较多用户输入内容的网站,我们就要对关键的接口做额外的防护措施。

    添加检验token

    由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在cookie中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中,其内容是一个随机数。即<input type="hidden" name="_csrf_token" value="xxxx">的形式。

    当客户端通过表单提交请求时,这个随机数也一并提交上去以供校验。正常的访问时,客户端浏览器能够正确得到并传回这个随机数,而通过CSRF传来的欺骗性攻击中,攻击者无从事先得知这个随机数的值,服务器端就会因为校验token的值为空或者错误,拒绝这个可疑请求。

    3. ClickJacking(点击劫持)

    3.1. 什么是点击劫持

    这是一种欺骗性比较强,同时也需要用户高度参与才能完成的一种攻击。通常的攻击步骤是这样的:

    1. 攻击者精心构造一个诱导用户点击的内容,比如Web页面小游戏
    2. 将我们的页面放入到iframe当中
    3. 利用z-index等CSS样式将这个iframe叠加到小游戏的垂直方向的正上方
    4. 把iframe设置为100%透明度
    5. 受害者访问到这个页面后,肉眼看到的是一个小游戏,如果受到诱导进行了点击的话,实际上点击到的却是iframe中的我们的页面

    点击劫持的危害在于,攻击利用了受害者的用户身份,在其不知情的情况下进行一些操作。如果只是迫使用户关注某个微博账号的话,看上去仿佛还可以承受,但是如果是删除某个重要文件记录,或者窃取敏感信息,那么造成的危害可就难以承受了。

    ​​​​​​​3.2. 如何防御

    有多种防御措施都可以防止页面遭到点击劫持攻击,例如Frame Breaking方案。一个推荐的防御方案是,使用X-Frame-Options:DENY这个HTTP Header来明确的告知浏览器,不要把当前HTTP响应中的内容在HTML Frame中显示出来。

    4. 文件上传漏洞

    4.1. 什么是文件上传漏洞

    文件上传漏洞是指用户上传了一个可执行的脚本文件(exe,php,asp,jsp,sh),并通过此脚本文件获得了执行服务器端命令的能力。文件上传功能本身是一个正常的业务需求,对于网站来说,很多时候也确实需要用户将文件上传到服务器。所以文件上传本身没有问题,但又问题的是文件上传后,服务器怎么处理、解释文件。如果服务器的处理逻辑做得不够安全,则会导致严重的后果。

    ​​​​​​​4.2. 常见防御措施

    § 文件扩展名服务端白名单校验,上传后的文件最好不可执行

    § 文件内容服务端校验。

    § 上传文件重命名,更改上传后的文件名,不与上传之前的文件名相同

    § 隐藏上传文件路径,如非必要,不要暴漏文件的访问路径

    ​​​​​​​5. 不安全的第三方依赖包

    npm 漏洞不容小觑,开发人员都需要重视 npm 的安全性,防止npm漏洞出现。

    ​​​​​​​5.1 Npm漏洞防御措施

    1、使用used次数多的npm包

    2、生产环境隐藏第三方依赖包或库版本号

    3不要盲目升级到新版本;尝试新的软件包版本之前先等其他人用一段时间来观察。

    4、在升级之前,请务必查看升级版本的更改日志和发行说明。

    5、始终审核你安装的第三方模块并做尽职调查,以确认其健康度和可信度

    展开全文
  • java和php安全性对比

    2021-02-12 18:19:33
    在编程领域,java这门编程语言可谓无人不知,无人不晓,应用领域也相当广泛。想比与java,php更适合的领域则体现在网站方面,二者各有...那么,作为开发人员,有一样东西是大家都要注意的,那就是安全性。那么二者的...

    20190831_5d69f65464960.jpg

    在编程领域,java这门编程语言可谓无人不知,无人不晓,应用领域也相当广泛。想比与java,php更适合的领域则体现在网站方面,二者各有优劣。

    对于java来说,更适合在大型应用系统施展手脚,应用前景广阔,系统维护性好,有着较高的可复用性;

    而对于php,则更适合快速的中小型应用开发,开发成本低,同时能够对变动的需求做出快速反应。那么,作为开发人员,有一样东西是大家都要注意的,那就是安全性。

    那么二者的安全性如何呢?接下来就为大家比较一下二者的安全性。

    安全性对比

    在JAVA的面前,PHP丢掉了很多的优势。在代码的安全性上尤为突出。PHP的开发程序在别人拿到代码后,可以很容易的进行修改。而JAVA开发的程序由于无法看到完整的源代码,只能看到一些编译好的类文件.class,所以安全性较高。

    加之系统架构的优势,在安全性上PHP和JAVA是相去甚远。如果非要将PHP和JAVA在安全性上做个比较的话,同一个小偷光顾PHP那是随便拿来随便改,想拿什么拿什么,拿的高兴还能大笔一挥某某到此一游。而光顾JAVA的时候,便会发现警察把守,内设自动报警装置,即便突破重重阻扰后进入居室。那值钱的东西都放在加密后的保险柜中,只能望洋兴叹、铩羽而归。

    显而易见的,从安全性来说java更胜一筹,不过对于实际工作中,还要看具体需求,并非安全性高就需要使用它。

    展开全文
  • 下面是一个很明显的例子:<In main.php:程序代码以下为引用的内容:<?php$libDir = "/libdir";......include("$libdir/loadlanguage.php":?>In libdir/loadlanguage.php:<?php...include("$langDir/$userLang"...
  • 我们来谈谈PHP网站一些常见安全防御措施,虽然简单但是能够有效保障网站的安全运行。1. 关闭全局变量的注册(register_globals),关闭display_errors,当然如果您希望得到出错信息,可以打开log_errors选项,并在...
  • 后面的系列文章将站在攻击者的角度,为你揭开PHP安全问题,同时提供相应应对方案。针对PHP的网站主要存在下面几种攻击方式:1、命令注入(Command Injection)2、eval注入(Eval Injection)3、客户端脚本攻击(Script ...
  • PHP网站安全性浅谈

    2021-04-24 15:12:08
    PHP网站安全性浅谈一、web应用服务安全性设置1、服务器各应用服务尽可能以独立用户运行,如:WEB服务运行帐户为wwwMySQL服务运行帐户为mysqlMemcached用户为memcacheRedis运行帐户为redis2、应用服务目录的读写权限...
  • 一、常见PHP网站安全漏洞 对于PHP的漏洞,目前常见的漏洞有五种。分别是Session文件漏洞、SQL注入漏洞、脚本命令执行漏洞、全局变量漏洞和文件漏洞。这里分别对这些漏洞进行简要的介绍。 1、session文件漏洞 ...
  • PHP安全-暴力攻击

    2021-04-26 11:55:07
    暴力攻击暴力攻击是一种不使用任何特殊手段而去穷尽各种可能攻击方式。它的更正式的叫法是穷举攻击——穷举各种可能攻击。对于访问控制,典型的暴力攻击表现为攻击者通过大量的尝试去试图登录系统。在多数...
  • 用Suhosin加强PHP脚本语言安全性PHP是一种非常流行的网站脚本语言,但是它本身所固有的安全性是非常薄弱。PHP增强计划(Hardened-PHP project)和新的Suhosi计划,Suhosin提供了增强的PHP的安全配置。PHP是带有争论地...
  • 接口的安全性主要围绕Token、Timestamp和Sign三个机制展开设计,保证接口的数据不会被篡改和重复调用,下面具体来看:(1)Token授权机制:(Token是客户端访问服务端的凭证)--用户使用用户名密码登录后服务器给客户端...
  • PHP安全-文件上传攻击

    2021-03-25 09:00:16
    文件上传攻击有时在除了标准的表单数据外,你还需要让用户进行文件上传。由于文件在表单中传送时与其它的表单数据不同,你必须指定一个特别的编码方式multipart/form-data:CODE:enctype="multipart/form-data">...
  • 用Suhosin加强PHP脚本语言安全性PHP是一种非常流行的网站脚本语言,但是它本身所固有的安全性是非常薄弱。PHP增强计划(Hardened-PHP project)和新的Suhosi计划,Suhosin提供了增强的PHP的安全配置。 PHP是带有争论地...
  • 我们都知道,在PHP开发中,$_SERVER[’PHP_SELF’],一般用来引用当前网页地址,即表示PHP文件相对于网站根目录地址,可以通过几个例子来看$_SERVER[’PHP_SELF’]的结果:http://www.example.com/php/test.php --&...
  • 但是,没有攻击手段并不意味着你不需要做一些简单的安全措施。新的攻击手段每天在出现,而简单的一个步骤能保护你的系统。 PHP提供了两个方便的函数以减轻这些理论上的风险:is_uploaded_file( ) and move_uploaded_...
  • PHP是一种非常流行的网站脚本语言,但是它本身所固有的安全性是非常薄弱。本文讲述了PHP增强计划(Hardened-PHP project)和新的Suhosi计划,Suhosin提供了增强的PHP的安全配置。PHP是带有争论地但又是最流行的一种...
  • php安全:全面解析跨站脚本攻击作为网站的业务管理者,在欣赏自己为客户提供的丰富业务和趣味体验时,你是否曾经想过网站会成为攻击攻击第三方的媒介,从而导致公信度大为受损?作为一个网站的访客,你是否曾经想...
  • PHP安全性防范方式

    2021-04-21 18:24:25
    SQL注入SQL注入是一种恶意攻击,用户利用在表单字段输入SQL语句的方式来影响正常的SQL执行。防范方式使用mysql_real_escape_string(),或者addslashes()过滤数据手动检查每一数据是否为正确的数据类型使用预处理语句...
  • 解析php安全性问题中的Null字符问题 由于 PHP 的文件系统操作是基于 C 语言的函数的,所以它可能会以您意想不到的方式处理 Null 字符。就跟随百分网小编一起去了解下吧,想了解更多相关信息请持续关注我们应届毕业...
  • 如何对PHP程序中的常见漏洞进行攻击(下)_php基发布时间:2016-06-17 来源: 点击:次如何对PHP程序中的常见漏洞进行攻击(下)翻译:analysist(分析家)来源:http://www.china4lert.org如何对PHP程序中的常见漏洞进行...
  • 我在一个WebAPP项目中遇到了... 这个思路可以: 拒绝不携带access_token的非法调用 防止无意间抓取到某个access_token,想利用该access_token做大规模攻击 当然,这里加密解密会牺牲掉一些性能,这也只是我的一种思路。
  • PHP网页的安全性问题

    2021-04-29 03:37:58
    针对PHP的网站主要存在下面几种攻击方式:1、命令注入(Command Injection)2、eval注入(Eval Injection)3、客户端脚本攻击(Script Insertion)4、跨网站脚本攻击(Cross Site Scripting, XSS)5、SQL注入攻击(SQL ...
  • 通常在编程中程序员要考虑的问题不仅是代码效率与代码复用,而且还要考虑一些安全问题{例如: SQL注入攻击XSS攻击任意执行代码文件包含以及CSRF.}关于SQL攻击有很多文章还有各种防注入脚本,但是都不能解决SQL注入的...
  • 现在有很多php开发框架都提供关于防XSS攻击的过滤方法,下面和大家分享一个预防XSS攻击和ajax跨域攻击的函数,主要去除了script等标签,下面直接上代码,不断的增加完善改进中。//去除xxs的攻击的公共方法public ...
  • 1、httponlysession一定要用httponly的否则可能被xxs攻击,利用js获取cookie的session_id。要用框架的ci_session,更长的位数,httponly,这些默认都配好了。不要用原生的phpsession,而要用ci_session。ci_session...
  • 1. SQL 注入攻击者控制通过 GET 和 POST 发送的查询(或者例如 UA 的一些其他查询)。一般情况下,你希望查询户名为「 peter 」的用户产生的 SQL 语句如下:SELECT * FROM users WHERE username = 'peter'但是,攻击者...
  • 一个网站建立以后,如果不注意安全方面的问题,很容易被人攻击,下面就讨论一下几种漏洞情况和防止攻击的办法跨站脚本攻击(XSS)跨站脚本攻击(XSS,Cross-site scripting)是最常见和基本的攻击WEB网站的方法。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 42,674
精华内容 17,069
关键字:

常见的php安全性攻击