前端安全专题

最新推荐文章于 2024-04-23 20:12:16 发布

️不倒翁

最新推荐文章于 2024-04-23 20:12:16 发布

阅读量1.0k

点赞数 17

分类专栏： javaScript 文章标签：前端安全 javascript

本文链接：https://blog.csdn.net/it_mr_wu/article/details/135568424

版权

javaScript 专栏收录该内容

23 篇文章 0 订阅

订阅专栏

xss (Cross Site Scripting) 跨站脚本攻击

原理

通常指黑客通过"HTML注入"篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。

常见攻击类型

存储型XSS

攻击者将恶意的 JavaScript 脚本存储在网站的服务器上（例如，在一个评论区中发布含有恶意脚本的评论）。当其他用户浏览到包含这些脚本的页面时，就会执行这些脚本。

反射型XSS

反射型XSS只是简单地把用户输入的数据”反射“给浏览器。也就是说黑客往往需要诱使用户”点击“一个恶意链接，才能攻击成功。反射型XSS也叫”非持久型XSS”。

<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title>Document</title>
</head>
<body>
  <div id="t"></div>
  <input type="text" id="text" value="" />
  <button onclick="test()" >提交</button>
  <script> 
  	function test() {
      var str = document.getElementById('text').value;
      document.getElementById('t').innerHTML = "<a href='" + str + "' >testLink</a>";} 
  </script>
 
</body>
</html> 


// 输入框构造如下数据：
' onclick=alert(/xss/) // 
// 它先用一个单引号闭合掉href的第一个单引号，然后插入一个onclick事件，最后再用注释符“//”注释掉第二个引号。 输入后，页面代码变成了：
<a href="" onclick="alert(/xss/)" '>testLink</a> 
// 点击新生成的这个链接，脚本将被执行。


// 其实这里还有另外一种利用方式，还可以选择闭合掉<a>标签，并插入一个新的HTML标签。尝试如下输入：
'><img src=# οnerrοr=alert(/xss2/) /><' 
// 页面代码变成了
<a href=""><img src="#" onerror="alert(/xss2/)"><''>testLink</a>

// 脚本直接被执行，弹出/xss2/。

DOM型XSS攻击

这种攻击是通过修改页面的 DOM 结构，使得恶意脚本得以执行。

CSRF(Cross-Site Request Forgery) 跨站请求伪造

利用的是网站对用户网页浏览器的信任。攻击者通过一些技术手段欺骗用户的浏览器去访问一个用户以前认证过的站点并运行一些操作（如发邮件，甚至进行财产操作如转账和购买商品等）。早期的网站用户和服务器的通信，是使用cookie进行认证的，而攻击者可以通过完全伪造用户的请求，因为请求中所有的用户验证信息都是存在于cookie中的。
多窗口浏览器（firefox、谷歌……）便捷的同时也带来了一些问题，因为多窗口浏览器新开的窗口是具有当前所有会话的。单窗口浏览器IE就不会，如我用ie登陆了我的Blog，然后我想看新闻了，又运行一个IE进程，这个时候两个IE窗口的会话是彼此独立的，从看新闻的IE发送请求到Blog不会有我登录的cookie；但是多窗口浏览器永远都只有一个进程，各窗口的会话是通用的，即看新闻的窗口发请求到Blog是会带上我在blog登录的cookie。

例子：

（1）用户在a站前端页面发起登录（身份认证）请求
（2）a站后端确认身份，登录成功，cookie中存在用户的身份认证信息
（3）b站前端页面向a站后端发起请求，带着a站的cookie信息（身份认证信息），请求成功
综上，可以清楚的知道，只要用户访问了b站的前端页面，b站就可以在用户完全不知道的情况下，带着a站的用户登录态（cookie）向a站发起请求

解决方案：

为了抵御这一攻击，现在的做法是让认证信息部分无法被伪造，同时用户的关键信息（如密码等）不能被直接查看到（一般是进行加密）。在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
此外，还有验证码、指纹、人脸等等，用于防御CSRF攻击。验证码强制用户必须与应用进行交互，才能完成最终请求，能很好的遏制CSRF攻击，但是用户体验比较差。
禁止第三方网站携带本网站的cookie信息：设置same-site属性，same-site属性有两个值，Strict（所有的第三方请求都不能携带本网站的cookie）和Lax（链接可以，但是form表单提交和ajax请求不行）

按钮点击劫持

是一种常见的网络攻击手段，也被称为“UI 覆盖攻击”。在这种攻击中，攻击者将一个透明的、恶意的网页覆盖在一个用户期望看到的网页上面。当用户在页面上进行操作（如点击按钮）时，他们实际上是在点击攻击者的透明页面，从而触发了攻击者预设的行为。
后果：用户自己做了点击操作，用户自己毫不知情

解决方案：

使用 X-Frame-Options HTTP 响应头：这是一种 HTTP 响应头，可以防止你的网页被嵌入到其他网页的 iframe 中。你可以将这个响应头设置为 DENY（禁止所有的域嵌入你的网页），或者 SAMEORIGIN（只允许相同域名的网页嵌入你的网页）。
使用 JavaScript 检测：你可以在你的网页中添加 JavaScript 代码，检测你的网页是否被嵌入到 iframe 中。

/**
Javascript禁止内嵌：当网页没有被使用iframe内嵌时，top和window是相等的；
当网页被内嵌时，top和window是不相等的；可以在本网站的页面中添加如下判断：
*/ 
<script>
if (top.location != window.location) {
    //如果不相等，说明使用了iframe，可进行相关的操作
}
</script>

一些辅助手段，比如添加验证码，提高用户的防范意识

sql注入

SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的sql语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

SSRF 服务器端请求伪造

一种由攻击者构造由服务端发起的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。(类似于请求代理转发的原理)

攻击目标

从外网无法访问的内部系统
对外网服务器所在内网，进行端口，z资源信息搜集

形成的原因

大部分是由于服务端提供了从其他服务器应用获取数据的功能，且没有对目标地址做过滤与限制

攻击方式

借助主机A来发起SSRF攻击，通过主机A向主机B发起请求，从而获取主机B的一些信息。

️不倒翁

关注

17
点赞
踩
24

收藏

觉得还不错? 一键收藏
打赏
0
评论
前端安全专题

早期的网站用户和服务器的通信，是使用cookie进行认证的，而攻击者可以通过完全伪造用户的请求，因为请求中所有的用户验证信息都是存在于cookie中的。SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的sql语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。在这种攻击中，攻击者将一个透明的、恶意的网页覆盖在一个用户期望看到的网页上面。
复制链接

扫一扫