SRF是Cross Site Request Forgery的缩写,翻译过来就是跨站请求伪造。 也被称为 one click attack/session riding,缩写为:CSRF/XSRF。
你这可以这么理解CSRF攻击:从一个网站A中发起一个到网站B的请求,而这个请求是经过了伪装的, 伪装操作达到的目的就是让请求看起来像是从网站B中发起的, 也就是说,让B网站所在的服务器端误以为该请求是从自己网站发起的,而不是从A网站发起的。当然,请求一般都是恶意的。
要真正理解为什么有CSRF攻击存在,那先了解几个浏览器的跨域访问限制。
cookie可以跨二级域名来访问,这个很好理解,例如你在www.cmj.com所在的web应用程序创建了一个cookie, 在cs.cmj.com这样的二级域名对应的应用程序中可以访问,当然你在创建cookie的时候需要指出Domain属性为cmj.com。 其他情况下的不同域名就无法访问这个cookie了。
js跨域是指通过js在不同的域之间进行数据传输或通信,比如用ajax向一个不同的域请求数据, 或者通过js获取页面中不同域的框架中(iframe)的数据。只要协议、域名、端口有任何一个不同,都被当作是不同的域。
在js中,我们直接用XMLHttpRequest请求不同域上的数据时,是不可以的。 但是,在页面上引入不同域上的js脚本文件却是可以的,jsonp正是利用这个特性来实现的。
如果你的页面使用jquery,那么通过它封装的方法就能很方便的来进行jsonp操作了。 普通的jquery的ajax调用方法基本都采用这个方式,所以就可以调用不同域名实现的API了。
$.getJSON方法会自动判断是否跨域,不跨域的话,就调用普通的ajax方法; 跨域的话,则会以异步加载js文件的形式来调用jsonp的回调函数。
浏览器的同源策略,不能通过ajax的方法去请求不同源中的文档。
我们只要把http://www.example.com/a.html 和 http://example.com/b.html这两个页面的document.domain都设成相同的域名就可以了。
CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的!
A网站访问B网站服务器的一些需要认证的资源的时候,如果没有Cookie信息,服务器是拒绝访问的,那么A网站就无法进行恶意操作。 而伪造成B网站的请求,就可以将B网站的Cookie一起发到B服务器,这个时候就服务器就认为该请求是合法的,就会给出正确的响应, 这个时候,A网站就达到目的了。
假设有一个微博网站B,B有一个“加关注”的功能,即一个用户可以关注另一个用户, 而这个功能是这样的实现的:用户每次点击“加关注”按钮的时候,就会向服务器发送一个GET请求,URL如下:
http://www.bdomain.com/addfriends?uid=123
URL中的参数uid表示的是你要关注的用户的ID。
在正常情况下,即你登录B网站后,点击“加关注”按钮,浏览器会将上面的URL连同B网站产生的Cookie一起发送到B网站的服务器, B服务器首先通过Cookie进行用户认证,如果Cookie中的信息正确,就会进行向数据库中写入记录,这样,你就成功关注了ID为123的用户。
假如我是一个恶意用户,我想让更多的人关注我,而我又不想通过正常的渠道去实现,因为毕竟正常渠道比较浪费时间, 于是我便开始想歪主意,碰巧,B网站的“加关注”的实现原理被我发现了。这个时候,我便进行了如下操作:
首先我在我自己的网站A里发了篇文章,文章中全是妖娆的美女图片,大家都喜欢美女嘛,所以就会有很多人来看我的这些美女, 我们知道,图片在网页中大都是通过<img scr="http://xxxx/xx.png"/>这样的形式实现的,图片加载的时候就会请求src中指定的URL, 而我就把众多美女图片的src写成了B博客里”加关注”的URL,不同的是将参数uid的值都写成了我在B网站中的ID(假设是456),即:
http://www.bdomain.com/addfriends?uid=456
浏览器一看请求的域名是bdomain.com,便将存放在客户端的B网站的Cookie给顺带一起发了过去。
借用别人的图文来说明一个整个CSRF的过程:
从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤:
防御效果是从服务端着手效果比较好,现在一般的CSRF防御也都在服务端进行。
所有表单都包含同一个伪随机值,这可能是最简单的解决方案了, 因为攻击者不能获得第三方的Cookie(理论上),所以表单中的数据也就构造失败了。
这个方法个人觉得已经可以杜绝99%的CSRF攻击了,那还有1%呢….由于用户的Cookie很容易由于网站的XSS漏洞而被盗取,这就另外的1%。
每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,这个方案可以完全解决CSRF,但个人觉得在易用性方面似乎不是太好。
推荐阅读:
Web常见安全漏洞-XSS攻击
Web常见安全漏洞-SQL注入
着互联网的发展,早已经不是仅限于简单的网页或是社交,电商购物、银行转账、企业管理等等。上次看到一个新闻,后台程序员离职后,利用职位之便,每天还不断的给自己转账,转了好多次才被发现,想想这多可怕。或者会窃取重要的商业信息,所以 Web 安全也是非常值得注意的。
什么是 Web 安全?
黑客利用网络操作系统的漏洞和 Web 服务器的 SQL 注入漏洞等,得到 Web 服务器的控制权,轻则篡改、删除、添加数据,重则窃取重要的商业信息、转账等,更严重的就是在网页中植入恶意代码,使网站受到不可预期的侵害。
常见的攻击可分为三类:XSS、CSRF、SQL注入。
Cross Site Scripting 跨站脚本攻击,为了与 CSS 区分,所以简写为 XSS 。
恶意攻击给 Web 页面植入恶意的 Script 代码,当用户浏览该网页的时候,嵌入 Web 里面的 script 代码会被执行,从而达到攻击的效果。
讲直白点,就是恶意攻击者通过在输入框处添加恶意 script 代码,用户浏览网页的时候执行 script 代码,从而达到恶意攻击用户的目的。
1.1、XSS 的危害
1.2、XSS 的攻击类型
发出请求时,XSS代码会出现在 url 中,作为输入提交到服务器端,服务器再返回给浏览器,然后浏览器解析执行 XSS 代码,这一过程像一次反射,所以称之为反射型。
这种类型的攻击,通常是把 XSS 攻击代码放入请求地址的 数据传输部分,如:
http://www.xxx.com?q=<script>alert("恶意脚本")</script>
或
http://www.xxx.com?n=<img sec="1 onerror=alert('恶意代码')">
提交的 XSS 代码会存储在服务器端,如数据库、内存、文件系统内,下次请求目标页面时不再提交 XSS 代码。
如在留言板输入框位置添加 script 代码或 html、css 代码,把代码为转义,直接存入数据库。
文档型的 XSS 攻击不会经过服务器,作为中间人的角色,在数据传输过程中劫持到网络数据包,然后修改里面的 html 文档。
1.3、XSS 的防御措施
措施1:编码。
对这些数据进行 html entity 编码。客户端和服务器端都需要进行转义编码。
<script>alert('恶意代码')</script>
转义后为:
<script>alert('恶意代码')</script>
放入上边的代码中,还是会自动解析为上边的代码,所以放到外边。
措施2:过滤。
移除用户上传的 DOM 属性,如上边的 onerror。
移除用户上传的 style、script、iframe 节点。
// 如
<div>
<style>
body { display:none }
</style>
</div>
措施3:利用 CSP
浏览器中的内容安全策略,就是决策浏览器加载哪些资源。
Cross site request forgery 跨站点请求伪造。
攻击者诱导受害者进入第三方网站,向被攻击网站发送跨站请求,利用被攻击者在被攻击网站已经获取的注册凭证,绕过后台的用户验证达到冒充用户对攻击网站进行的某种操作。
CSRF 攻击特点:
2.1、CSRF 的危害
2.2、CSRF 的攻击类型
使用非常简单,只需要一个 http 请求。
比如页面中的一个图片添加链接,还有 iframe、script ,最容易完成 CSFR 攻击,且不易被用户发现,隐蔽性超强。
由于 get 接口是最常见的一种 CSRF 攻击类型,所以很多重要的接口不适用 get 方式,使用 post 一定程度上可以防止 CSRF 攻击。
这种类型的 SCRF 攻击,通常使用的是一个自动提交的表单。简单讲就是伪造一个自动提交的表单,一旦访问页面时,表单就会自动提交。
如:
<form action="http://xxx.com/widthdraw" method="post">
<input type="hidden" name="account" value="web" />
<input type="hidden" name="psd" value="hacker" />
</form>
<script type="text/javascript">
document.forms[0].submit()
</script>
比起前两个,这个类型的比较少见,链接类型的攻击必须要用户点击链接,才能触发。
通常在论坛中发布的图片嵌入恶意的链接,或以广告的形式诱导用户点击中招。所以我们在邮箱中看到乱七八糟的广告,尽量别点击,防止遇到三方攻击。
伪造一种新型的攻击方式,用户误以为是在网站正常登录,实际上是使用账户和密码登录到了黑客网站,这样黑客可以监听到用户的所有操作,甚至知道用户的账户信息。
2.3、CSRF 的防御措施
措施1:检查 http 头部的 referer 信息
referer 包含在请求头内,表示请求接口的页面来源。
服务端通过检查 referer 信息,发现来源于外域时,就可以拦截请求,通过阻止不明外域的访问,一定程度上可以减少攻击。
措施2:使用一次性令牌
使用一次性令牌做身份识别,黑客是无法通过跨域拿到一次性令牌的,所以服务端可以通过判断是否携带一次性令牌,就可以排除一部分的非法操作者。
措施3:使用验证图片
服务端生成一些文本和数字,在服务端保存这份信息,同时以图片的形式在客户端展现,让用户去合法填写信息,当 CSRF 攻击时,拿不到这个验证码的时候,无法向服务器提供这个信息,导致匹配失败,从而识别它是非法攻击者。
这个应用非常常见,之前登录的时候,需要填写图形验证码。
现在滑动图片验证也非常常见。
SQL 注入,一般发生在注册、评论、添加等,只有有用户输入的地方,就有可能发生 SQL 注入。SQL 注入是一种常见的 Web 安全漏洞,攻击者会利用这个漏洞,可以访问或修改数据,利用潜在的数据库漏洞进行攻击。
所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。具体来说,它是利用现有应用程序,将(恶意的)SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.
3.1、SQL 注入危害
任意的账号都可以登录,可以进行任意的操作,粗暴点讲,就是随便来。
3.2、 SQL注入分类
当输入的参数为整数时,则有可能存在数字型漏洞。
当输入参数为字符串时,则可能存在字符型注入漏洞。数字型与字符型注入最大的区别在于:数字型不需要单引号闭合,而字符型一般需要使用单引号来闭合。
字符型注入最关键的是如何闭合 SQL 语句以及注释多余的代码。
其实我觉得 SQL 注入只有两种类型:数字型与字符型。很多人可能会说还有如:Cookie 注入、POST 注入、延时注入等。
的确如此,但这些类型的注入归根结底也是数字型和字符型注入的不同展现形式或者注入的位置不同罢了。
以下是一些常见的注入叫法:
3.3、SQL注入的防范措施
凡是用户输入的地方,我们都应该防止黑客攻击,永远不要相信用户的输入。所以对应的防御措施分别有:
前后端分离之后,前端每天都会接触到很多接口。发送网络请求的时候,有些接口就会使用 get 方法。最常见的传参方式就是,直接在 url 地址后面加参数。
https://www.so.com/s?q='Web前端'
直接采用这种方式传输数据,如果数据被劫持或抓包工具偷走之后,就会直接被人盗取走,特别危险。若是采用接口加密,如下:
// 百度关键字查找示例
// 接口采用 get 方式
https://www.so.com/s?q=get%E4%BC%A0%E5%8F%82%E6%96%B9%E5%BC%8F&src=srp_suggst_revise&fr=se7_newtab_big&psid=014cd859f04a9ba923802a92f6821d44&eci=&nlpv=base_yc_52
上边那个看不懂的一长串符号,正是经过加密的数据。
接口加密就是将接口请求调用中传递的参数进行加密,目的就是为了保证接口请求中传递参数和返回的结果的安全性,一般比较敏感数据,如身份证、电话号码、账号、密码等需要进行加密。
常见的加密方式:
加密方式较多,可以根据自己具体的需要和项目语言选择其中一种。
加密之后的数据更安全,那我们能不能将接口所有的数据都进行加密呢?加密是非常消耗资源的,如果有大批量的数据都进行加密时,返回数据需要的时间就更长,会直接影响用户体验。所以我们进行加密时,只需要对敏感的重要的信息进行加密。
好了小编今天的文章就到此结束了,本篇文章没有介绍到的 web 安全,欢迎评论区交流!
用户在 HTML 表单中填写并提交数据时,可以使用 PHP 来接收并处理这些数据。要实现这一点,需要创建一个 PHP 脚本来处理提交的数据,然后将 HTML 表单的 "action" 属性设置为该脚本的文件路径。表单提交的数据需要进行验证和过滤,以确保数据的完整性和安全性。可以使用条件语句、正则表达式、过滤器函数等方法来验证和过滤数据,并使用 htmlspecialchars() 函数转义 HTML 标记,以防止 XSS 攻击。
以下是一个简单的示例:
HTML 表单代码:
<form action="submit.php" method="post">
<label for="name">Name:</label>
<input type="text" id="name" name="name">
<label for="email">Email:</label>
<input type="email" id="email" name="email">
<button type="submit">Submit</button>
</form>
PHP 代码(submit.php):
<?php
// 获取表单提交的数据
$name=$_POST['name'];
$email=$_POST['email'];
// 在这里进行处理,例如将数据存储到数据库中
// ...
// 返回一个响应,告诉用户数据已经被成功提交
echo "Thank you for submitting the form, $name!";
?>
在上面的示例中,表单的 "action" 属性设置为 "submit.php",这意味着提交表单时,数据将被发送到 submit.php 文件中的 PHP 代码中进行处理。PHP 代码使用 $_POST 数组来获取表单提交的数据,然后进行处理,例如将数据存储到数据库中。最后,PHP 代码返回一个响应,告诉用户数据已经被成功提交。在处理表单数据时,一定要对用户输入进行验证和过滤,以防止安全漏洞。
需要对表单提交的数据进行验证和过滤,以确保数据的完整性和安全性。以下是一些常见的方法:
1、验证表单字段:在 PHP 代码中使用条件语句和正则表达式等方法来验证表单字段的有效性,例如验证电子邮件地址的格式是否正确。
$email=$_POST['email'];
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
// 如果邮件地址格式不正确,则显示错误消息
echo "Invalid email address";
}
2、过滤输入数据:使用 PHP 中的过滤器函数来过滤表单输入数据,以防止 XSS 攻击和 SQL 注入等安全漏洞。
$name=$_POST['name'];
$name=filter_var($name, FILTER_SANITIZE_STRING); // 过滤特殊字符和标签
3、防止跨站脚本攻击(XSS):在 PHP 代码中使用 htmlspecialchars() 函数来转义 HTML 标记,防止恶意脚本注入到页面中。
$name=$_POST['name'];
$name=htmlspecialchars($name, ENT_QUOTES, 'UTF-8'); // 转义 HTML 标记
4、防止 SQL 注入攻击:在 PHP 代码中使用参数化查询或准备语句来执行数据库操作,以防止恶意 SQL 语句注入到数据库中。
$stmt=$pdo->prepare("INSERT INTO users (name, email) VALUES (:name, :email)");
$stmt->bindParam(':name', $name);
$stmt->bindParam(':email', $email);
$stmt->execute();
通过这些方法,可以确保表单提交的数据是安全和有效的,并且能够正常地处理和存储到数据库中。
*请认真填写需求信息,我们会在24小时内与您取得联系。