Loading...

整理的一些前端安全问题

发布者 milleros - 8 个月前

Web security 1.0

主要整理了前端的一些常见的安全问题。

JS逻辑代码

1. XSS攻击

主要表现为注入代码,在客户端渲染数据时,应该无条件相信用户的输入是不可信的,也就是说当渲染用户输入的数据时,应当提前剔除可执行代码或者直接进行转义。 XSS攻击通常是下面的攻击形式:

  • 使用vue等框架渲染时
<div class="content" v-html="data.content"></div> <!-- 🈲直接渲染用户的输入为html -->
<div class="content">{{data.content}}</div> <!-- ✅使用带有转义作用的渲染方式 -->
<script>
    data(){
        return {
            content:"<script>alert('您被XSS攻击了')</script>"
        }
    }
</script>
  • 使用JS、JQ渲染数据时
<div class="content"></div>
<script>
    var _incomeMsg = '<script>alert('您被XSS攻击了')</script>';

    document.getElementByClass('content')[0].innerHtml = _incomeMsg; // 🈲直接渲染用户的输入为html
    document.getElementByClass('content')[0].innerText = _incomeMsg; // ✅使用带有转义作用的渲染方式

    $('.content').append(_incomeMsg);// 🈲直接渲染用户的输入为html
    $('.content').after(_incomeMsg);// 🈲直接渲染用户的输入为html
    $('.content').before(_incomeMsg);// 🈲直接渲染用户的输入为html

    $('.content').text(_incomeMsg);// ✅使用带有转义作用的渲染方式
</script>

<!-- 执行exec等函数 -->
<script>
function html2Escape(sHtml) {
 return sHtml.replace(/[<>&"]/g,function(_index){
   return {'<':'&lt;','>':'&gt;','&':'&amp;','"':'&quot;'}[_index];
 });
}

var _url = "https://lingtaikj.com?username=<script>alert('您被XSS攻击了')</script>"
var param = /=(.+)$/.exec(_url);
var value = decodeURIComponent(param[1]);

$('.content').append('<a class="appendLink">' + _url + '</a>');// 🈲直接渲染用户的输入为html
$('.content').append('<a class="appendLink">' + html2Escape(_url) + '</a>');// ✅使用函数将html标签转换为实体编码
</script>

2. CSRF攻击

CSFR跨站请求伪造攻击,主要利用不合理的POST或GET请求来达成某种目的。

2.1 GET请求

某些时候,一些后端工程师为了方便,会将某些post请求写成GET请求,殊不知这样是违反HTTP标准的,同时也容易被黑客所利用:

<?php
// 从cookie中获取用户名,看似稳妥
$username = $_COOKIE['username'];
$productId = $_GET['pid'];
// 这里进行购买操作
//store_into_database($username, $productId);
?>
<meta charset="utf-8" />
<?php
echo $username . '买入商品:' . $productId;
?>

此时我们直接使用浏览器访问目标端口即可达成请求

2.2 POST请求

虽然我们此时按照了HTTP标准来编写请求接口,但是此时还是可以破解的。

<?php
$username = $_COOKIE['username'];
// 换为post了,可以规避黑客直接的提交
$productId = $_POST['pid'];
// 这里进行购买操作
//store_into_database($username, $productId);
?>
<meta charset="utf-8" />
<?php
echo $username . '买入商品:' . $productId;
?>

此时在html网页中可以伪造一个表单等待用户点击。

<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
        <script src="https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/js/lib/jquery-1.10.2_d88366fd.js"></script>
    </head>
    <body>
        <button id="clickme">点我看相册</button>
        <script>
            $('#clickme').on('click', function () {
                // 用户再不知情的情况下,提交了表单,服务器这边也会以为是用户提交过来的。
                $('#myform').submit();
            });
        </script>
        <form id="myform" style="display:none;" target="myformer" method="post" action="http://myhost:8082/lab/xsrflab/submit.php">
            <input type="hidden" name="pid" value="1">
        </form>
        <iframe name="myformer" style="display:none;"></iframe>
    </body>
</html>

2.3 如何防范两种请求潜在的CSRF攻击

除了要遵守HTTP标准来编写接口以外,我们可以在请求时给请求加上验证码,如果验证码填写不对,则请求无效,但是缺点是降低用户体验,用户每次请求都需要输入验证码,这是极其不友好的。

另外一种方法是在POST等敏感请求上加上二次验证,即在每个请求上加上页面token验证,当用户每次访问某个页面时,生成一个token下发给用户,当用户请求时验证token是否有效,这样当黑客在使用CSRF时则不会带有网站生成的请求Token,此连接操作自然是无效的。

3. 网络劫持

3.1 HTTP劫持

很多的时候,我们的网站不是直接就访问到我们的服务器上的,中间会经过很多层代理,如果在某一个环节,数据被中间代理层的劫持者所截获,他们就能获取到使用你网站的用户的密码等保密数据。比如,我们的用户经常会在各种饭馆里面,连一些奇奇怪怪的wifi,如果这个wifi是黑客所建立的热点wifi,那么黑客就可以结果该用户收发的所有数据。这里,建议站长们网站都使用https进行加密。这样,就算网站的数据能被拿到,黑客也无法解开。

如果你的网站还没有进行https加密的化,则在表单提交部分,最好进行非对称加密--即客户端加密,只有服务端能解开。这样中间的劫持者便无法获取加密内容的真实信息了。

3.2 iframe劫持

此种表现为自己的网站被其他网站利用iframe嵌套了,如果我们的网站因为某些原因被第三方网站嵌套了,第三方网站可以将嵌套我们网站的iframe透明度设为0覆盖在当前网页之上,然后利用背景诱导用户点击,那么此时就有可能发生不可预料的风险。

解决方法

3.2.1 防网页被嵌套

为了防止网站被钓鱼,可以使用window.top来防止你的网页被iframe.

//禁止任意形式的被嵌套
if(window != window.top){
    window.top.location.href = correctURL;
}

//同域名的网页可嵌套
if (top.location.host != window.location.host) {
  top.location.href = window.location.href;
}
3.2.2 X-Frame-Options

X-Frame-Options是一个响应头,主要是描述服务器的网页资源的iframe权限。目前的支持度是IE8+

X-Frame-Options: DENY
拒绝任何iframe的嵌套请求

X-Frame-Options: SAMEORIGIN
只允许同源请求,例如网页为 foo.com/123.php,則 foo.com 底下的所有网页可以嵌入此网页,但是 foo.com 以外的网页不能嵌入

X-Frame-Options: ALLOW-FROM http://s3131212.com
只允许指定网页的iframe请求,不过兼容性较差Chrome不支持
3.3.3 CSP页面防护

和X-Frames-Options一样,都需要在服务器端设置好相关的Header. CSP 的作用, 真的是太大了,他能够极大的防止你的页面被XSS攻击,而且可以制定js,css,img等相关资源的origin,防止被恶意注入。不过兼容性不好。

Content-Security-Policy: default-src 'self'
3.2.2 sandbox

主要用于防止自己的网页嵌套他人网站时的安全问题

<iframe sandbox src="..."> ... </iframe>

sandbox还忠实的实现了“Secure By Default”原则,也就是说,如果你只是添加上这个属性而保持属性值为空,那么浏览器将会对iframe实施史上最严厉的调控限制,基本上来讲就是除了允许显示静态资源以外,其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等,连Origin都会被强制重新分配一个唯一的值,换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。 另外,sandbox也提供了丰富的配置参数,我们可以进行较为细粒度的控制。一些典型的参数如下:

allow-forms:允许iframe中提交form表单
allow-popups:允许iframe中弹出新的窗口或者标签页(例如,window.open(),showModalDialog(),target=”_blank”等等)
allow-scripts:允许iframe中执行JavaScript
allow-same-origin:允许iframe中的网页开启同源策略

4. 控制台注入代码

通常此种攻击方式较为罕见,主要表现为黑客利用不懂代码的小白,诱骗他们在控制台粘贴执行某些代码,从而达到窃取用户信息的目的。

解决方案 在控制台显著标识警示信息。可参考天猫官网,打开控制台查看安全警告

5. 钓鱼网站

一般钓鱼网站会伪造成和正常网站,此时提示用户输入账号密码,提交之后用户对方便获得了用户的账号密码等信息。

一般是在原网站上发布钓鱼网站的外链,诱导用户点击。

解决办法 在网站内所有不可信的外链均执行页面unload提示,或者将所有的不可信外链改成拦截后需要用户确认为新窗口打开。

Cookie安全

Cookie主要是用来维护用户的登录状态的,同时有可能会存储其他敏感信息;当我们网页中的Cookie被他人,例如黑客利用XSS攻击或者其他方式获取了您的Cookie,那么他将可以利用您的Cookie以您的身份登录网站并进行操作。

  • 解决办法 要解决用户的Cookie可能被窃取的问题,通常的做法是后端工程师在处理登录注册操作时将用户的cookie设置为HttpOnly
setcookie("Session", "sessionKey", NULL, NULL, NULL, NULL, TRUE/*httpOnly*/);

标签纵览

SSH(1)Docker(1)Python(1)VueJS(2)Nodejs(2)Linux(5)前端(8)