前端常见的安全问题以及防范措施总结大全

目录
  • 前言
  • 前端安全问题
  • 跨站脚本攻击(XSS)
    • 反射型XSS攻击
    • 基于DOM的XSS攻击
    • 存储型XSS攻击
    • 这几种XSS攻击类型的区别
    • XSS防范措施
      • 输入过滤
      • 预防存储型和反射型XSS攻击
      • 预防DOM型XSS攻击
      • ContentSecurityPolicy
      • 其他措施
    • XSS攻击案例
  • 跨站请求伪造(CSRF)
    • CSRF是怎么攻击的?
    • 常见的CSRF攻击类型
      • GET类型的CSRF
      • POST类型的CSRF
      • 链接类型的CSRF
    • CSRF的特点
    • CSRF防范措施
      • 同源检测
      • CSRFToken
      • 给Cookie设置合适的SameSite
  • 点击劫持(ClickJacking)
    • 点击劫持防范措施
  • HTTP严格传输安全(HSTS)
    • 开启HSTS
  • CDN劫持
    • CDN原理?
    • 什么是CDN劫持?
    • CDN劫持防范措施
      • 使用SRI来解决CDN劫持
      • 浏览器如何处理SRI
  • 内容安全策略(CSP)
    • CSP的意义
    • CSP的分类
    • CSP的使用
      • 如何让自己的网站不被其他网站的iframe引用?
      • 如何禁止被使用的iframe对当前网站某些操作?
  • 安全沙箱(Sandbox)
  • Iframe
  • 总结

前言

随着互联网的高速发展,信息安全问题已经成为行业最为关注的焦点之一。总的来说安全是很复杂的一个领域,在移动互联网时代,前端人员除了传统的 XSS、CSRF 等安全问题之外,还时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。这篇文章会介绍一些常见的安全问题及如何防范的内容,在当下其实安全问题越来越重要,已经逐渐成为前端开发必备的技能了。

前端安全问题

跨站脚本攻击(XSS)

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

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

一般可以通过三种方式来注入恶意脚本:

反射型XSS攻击

顾名思义,恶意 JavaScript 脚本属于用户发送给网站请求中的一部分,随后网站又将这部分返回给用户,恶意脚本在页面中被执行。一般发生在前后端一体的应用中,服务端逻辑会改变最终的网页代码。

反射型 XSS 的攻击步骤:

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

基于DOM的XSS攻击

目前更流行前后端分离的项目,反射型 XSS 无用武之地。 但这种攻击不需要经过服务器,我们知道,网页本身的 JavaScript 也是可以改变 HTML 的,黑客正是利用这一点来实现插入恶意脚本。

基于DOM 的 XSS 攻击步骤:

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

存储型XSS攻击

又叫持久型 XSS,顾名思义,黑客将恶意 JavaScript 脚本长期保存在服务端数据库中,用户一旦访问相关页面数据,恶意脚本就会被执行。常见于搜索、微博、社区贴吧评论等。

存储型 XSS 的攻击步骤:

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

这几种XSS攻击类型的区别

  • 反射型的 XSS 的恶意脚本存在 URL 里,存储型 XSS 的恶意代码存在数据库里。
  • 反射型 XSS 攻击常见于通过 URL 传递参数的功能,如网站搜索、跳转等。
  • 存储型XSS攻击常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等。
  • 而基于DOM的XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,其他两种 XSS 都属于服务端的安全漏洞。

XSS防范措施

由上面对XSS攻击的介绍我们知道,XSS攻击主要有两大步骤:

  • 攻击者提交恶意代码
  • 浏览器执行恶意代码

所以我们可以针对这两点来制定防范措施:

输入过滤

在用户提交时,由前端过滤输入,然后提交到后端,这种方法不可行,因为攻击者可能绕过前端过滤,直接构造请求,提交恶意代码。一般在写入数据库前,后端对输入数据进行过滤。虽然输入侧过滤能够在某些情况下解决特定的 XSS 问题,但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。

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

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

预防 DOM 型 XSS 攻击

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

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

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

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

<!-- 内联事件监听器中包含恶意代码 -->
<img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">

<!-- 链接内包含恶意代码 -->
<a href="UNTRUSTED" rel="external nofollow" >1</a>

<script>
// setTimeout()/setInterval() 中调用恶意代码
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")

// location 调用恶意代码
location.href = 'UNTRUSTED'

// eval() 中调用恶意代码
eval("UNTRUSTED")
</script>

Content Security Policy

严格的 CSP 在 XSS 的防范中可以起到以下的作用:

  • 禁止加载外域代码,防止复杂的攻击逻辑。
  • 禁止外域提交,网站被攻击后,用户的数据不会泄露到外域。
  • 禁止内联脚本执行(规则较严格,目前发现 GitHub 使用)。
  • 禁止未授权的脚本执行(新特性,Google Map 移动版在使用)。
  • 合理使用上报可以及时发现 XSS,利于尽快修复问题。

使用 W3C 提出的 CSP (Content Security Policy,内容安全策略),定义域名白名单

其他措施

  • 设置 Cookie 的 HttpOnly 属性,禁止JavaScript读取cookie
  • 验证码:防止脚本冒充用户提交危险操作。

XSS攻击案例

  • 2005年,年仅19岁的 Samy Kamkar 发起了对 MySpace.com 的 XSS Worm 攻击。 Samy Kamkar 的蠕虫在短短几小时内就感染了100万用户——它在每个用户的自我简介后边加了一句话:“but most of all, Samy is my hero.”(Samy是我的偶像)。这是 Web 安全史上第一个重量级的 XSS Worm,具有里程碑意义。
  • 2007年12月,百度空间收到蠕虫攻击,用户之间开始转发垃圾短消息。
  • QQ 邮箱 m.exmail.qq.com 域名被发现反射型 XSS 漏洞
  • 2011年新浪微博曾被黑客 XSS 攻击,黑客诱导用户点击一个带有诱惑性的链接,便会自动发送一条带有同样诱惑性链接微博。攻击范围层层扩大,也是一种蠕虫攻击。

跨站请求伪造(CSRF)

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

CSRF是怎么攻击的?

典型的CSRF攻击是这样的:

  • 受害者登录A网站,并且保留了登录凭证(Cookie)
  • 攻击者引诱受害者访问B网站
  • B网站向A网站发送了一个请求(这个就是下面将介绍的几种伪造请求的方式),浏览器请求头中会默认携带 A 网站的 Cookie
  • A 网站服务器收到请求后,经过验证发现用户是登录了的,所以会处理请求

常见的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" rel="external nofollow"  taget="_blank">
  重磅消息!!
  <a/>

CSRF的特点

  • 攻击一般发起在第三方网站,而不是被攻击的网站。被攻击的网站无法防止攻击发生。
  • 攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据。
  • 整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”。
  • 跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中,难以进行追踪。

CSRF防范措施

由上面对CSRF的介绍我们知道了,CSRF通常发生在第三方域名,并且CSRF攻击者不能获取到受害者的cookie等信息,只是借用他们的登录状态来伪造请求。所以我们可以针对这两点来制定防范措施:

同源检测

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

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

  • Origin Header
  • Referer Header

这两个Header在浏览器发起请求时,大多数情况会自动带上,并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名,确定请求的来源域。同时服务器应该优先检测 Origin。为了安全考虑,相比于 Referer,Origin 只包含了域名而不带路径。

CSRF Token

  • 在浏览器向服务器发起请求时,服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的随机字符串,然后将该字符串植入到返回的页面中,通常是放到表单的隐藏输入框中,这样能够很好的保护 CSRF Token 不被泄漏;
  • 当浏览器再次发送请求的时候,就需要携带这个 CSRF Token 值一起提交;
  • 服务器验证 CSRF Token 是否一致;从第三方网站发出的请求是无法获取用户页面中的 CSRF Token 值的。

给 Cookie 设置合适的 SameSite

当从 A 网站登录后,会从响应头中返回服务器设置的 Cookie 信息,而如果 Cookie 携带了 SameSite=strict 则表示完全禁用第三方站点请求头携带 Cookie,比如当从 B 网站请求 A 网站接口的时候,浏览器的请求头将不会携带该 Cookie。

  • Samesite=Strict,这种称为严格模式,表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie
  • Samesite=Lax,这种称为宽松模式,比 Strict 放宽了点限制:假如这个请求是这种请求(改变了当前页面或者打开了新页面)且同时是个GET请求,则这个Cookie可以作为第三方Cookie。(默认)
  • None 任何情况下都会携带;

点击劫持(ClickJacking)

点击劫持(Clickjacking)是一种通过视觉欺骗的手段来达到攻击目的手段。往往是攻击者将目标网站通过 iframe 嵌入到自己的网页中,通过 opacity 等手段设置 iframe 为透明的,使得肉眼不可见,这样一来当用户在攻击者的网站中操作的时候,比如点击某个按钮(这个按钮的顶层其实是 iframe),从而实现目标网站被点击劫持。

点击劫持防范措施

  • 在HTTP投中加入 X-FRAME-OPTIONS 属性,此属性控制页面是否可被嵌入 iframe 中

    • DENY:不能被所有网站嵌套或加载;
    • SAMEORIGIN:只能被同域网站嵌套或加载;
    • ALLOW-FROM URL:可以被指定网站嵌套或加载。
  • 判断当前网页是否被 iframe 嵌套

HTTP严格传输安全(HSTS)

HTTP严格传输安全(HSTS)是一种安全功能,web服务器通过它来告诉浏览器仅用HTTPS来与之通讯,而不是使用HTTP。

HSTS代表HTTP严格传输安全性,由IETF在2012年的RFC 6797中指定。创建它是为了在站点通过HTTPS运行时强制浏览器使用安全连接。它是您添加到Web服务器的安全标头,并在响应标头中反映为Strict-Transport-Security。HSTS很重要,因为它解决了以下问题:

  • 访问者尝试使用您网站页面的不安全版本 (HTTP://) 的任何尝试都将自动转发到安全版本 (HTTPS://)。
  • 旧的HTTP书签和输入您网站的HTTP版本的人会让您面临中间人攻击。在这些攻击中,攻击者改变各方之间的通信并诱使他们认为他们仍在相互通信。
  • 不允许覆盖无效的证书消息,这反过来又保护了访问者。
  • Cookie劫持:当有人通过不安全的连接窃取会话cookie时,就会发生这种情况。Cookie可以包含各种有价值的信息,例如信用卡信息、姓名、地址等。

注意,如果之前没有使用HTTPS协议访问过该站点,那么HSTS是不奏效的,只有浏览器曾经与服务器创建过一次安全连接并且网站通过HTTPS协议告诉浏览器它支持HSTS,那么之后浏览器才会强制使用HTTPS,即使链接被换成了HTTP。

虽然我们的系统默认更喜欢HTTPS版本,但您也可以通过将您的HTTP站点重定向到您的HTTPS版本并在您的服务器上实施HSTS标头,使其他搜索引擎更清楚这一点。 —— 谷歌安全团队

开启HSTS

在Apache中启用HSTS

将以下代码添加到您的虚拟主机文件中。

Header always set Strict-Transport-Security max-age=31536000

在NGINX中启用 HSTS

将以下代码添加到您的NGINX配置中。

add_header Strict-Transport-Security max-age=31536000

事实上,添加HSTS标头有性能优势。如果有人试图通过HTTP访问您的站点,而不是发出HTTP请求,它只是重定向到HTTPS版本。

CDN劫持

CDN原理?

它的名字就叫做CDN——Content Delivery Network,内容分发网络。具体来说,CDN就是采用更多的缓存服务器(CDN边缘节点),布放在用户访问相对集中的地区或网络中。当用户访问网站时,利用全局负载技术,将用户的访问指向距离最近的缓存服务器上,由缓存服务器响应用户请求。(有点像电商的本地仓吧?)CDN应用广泛,支持多种行业、多种场景内容加速,例如:图片小文件、大文件下载、视音频点播、直播流媒体、全站加速、安全加速。

什么是CDN劫持?

网络上有很多黑客为了让用户能够登录自己开发的钓鱼网站,都会通过对CDN进行劫持的方法,让用户自动转入自己开发的网站。而很多用户却往往无法察觉到自己已经被劫持。其实验证被劫持的方法,就是输入任何网址看看所打开的网页是否和自己输入的网址一致,

CDN劫持防范措施

使用SRI来解决CDN劫持

SRI 全称 Subresource Integrity - 子资源完整性,是指浏览器通过验证资源的完整性(通常从 CDN 获取)来判断其是否被篡改的安全特性。

通过给 link 标签或者 script 标签增加 integrity 属性即可开启 SRI 功能,比如

<script type="text/javascript" src="https://s.url.cn/xxxx/aaa.js"
    integrity="sha256-xxx sha384-yyy"
    crossorigin="anonymous"></script>

integrity 值分成两个部分,第一部分指定哈希值的生成算法(sha256、sha384 及 sha512),第二部分是经过 base64 编码的实际哈希值,两者之间通过一个短横(-)分割。integrity 值可以包含多个由空格分隔的哈希值,只要文件匹配其中任意一个哈希值,就可以通过校验并加载该资源。开启 SRI 能有效保证页面引用资源的完整性,避免恶意代码执行。

浏览器如何处理 SRI

  • 当浏览器在 script 或者 link 标签中遇到 integrity 属性之后,会在执行脚本或者应用样式表之前对比所加载文件的哈希值和期望的哈希值。
  • 当脚本或者样式表的哈希值和期望的不一致时,浏览器必须拒绝执行脚本或者应用样式表,并且必须返回一个网络错误说明获得脚本或样式表失败。

内容安全策略(CSP)

内容安全策略(Content Security Policy)简称 CSP,通过它可以明确的告诉客户端浏览器当前页面的哪些外部资源可以被加载执行,而哪些又是不可以的。

CSP的意义

防XSS等攻击的利器。CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。它的实现和执行全部由浏览器完成,开发者只需提供配置。CSP 大大增强了网页的安全性。攻击者即使发现了漏洞,也没法注入脚本,除非还控制了一台列入了白名单的可信主机。

CSP的分类

  • Content-Security-Policy 配置好并启用后,不符合 CSP 的外部资源就会被阻止加载。
  • Content-Security-Policy-Report-Only 表示不执行限制选项,只是记录违反限制的行为。它必须与report-uri选项配合使用。

CSP的使用

  • 通过 HTTP 头配置 Content-Security-Policy,以下配置说明该页面只允许当前源和 https://apis.google.com 这 2 个源的脚本加载和执行:
Content-Security-Policy: script-src 'self' https://apis.google.com
  • 通过页面 <meta> 标签配置:
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

安全沙箱(Sandbox)

多进程的浏览器架构将主要分为两块:浏览器内核和渲染内核。而安全沙箱能限制了渲染进程对操作系统资源的访问和修改,同时渲染进程内部也没有读写操作系统的能力,而这些都是在浏览器内核中一一实现了,包括持久存储、网络访问和用户交互等一系列直接与操作系统交互的功能。浏览器内核和渲染内核各自职责分明,当他们需要进行数据传输的时候会通过 IPC 进行。

而渲染进程的工作是进行 HTML、CSS 的解析,JavaScript 的执行等,而这部分内容是直接暴露给用户的,所以也是最容易被黑客利用攻击的地方,如果黑客攻击了这里就有可能获取到渲染进程的权限,进而威胁到操作系统。所以需要一道墙用来把不可信任的代码运行在一定的环境中,限制不可信代码访问隔离区之外的资源,而这道墙就是浏览器的安全沙箱。

安全沙箱的存在是为了保护客户端操作系统免受黑客攻击,但是阻止不了 XSS 和 CSRF。

安全沙箱是利用操作系统提供的安全技术,这样渲染进程在运行中就无法获取或修改操作系统中的数据。安全沙箱最小隔离单位是进程,所以无法保护单进程浏览器。

Iframe

iframe在给我们的页面带来更多丰富的内容和能力的同时,也带来了不少的安全隐患。因为iframe中的内容是由第三方来提供的,默认情况下他们不受我们的控制,他们可以在iframe中运行JavaScirpt脚本、Flash插件、弹出对话框等等,这可能会破坏前端用户体验。

如何让自己的网站不被其他网站的iframe引用?

  • js的防御方案:将下面这段代码放到网站页面的</body>标签前,这样别人在通过iframe框架引用你的网站网页时,浏览器会自动跳转到你的网站所引用的页面上。

    <script>
    if (self == top) {
        var theBody = document.getElementsByTagName('body')[0];
        theBody.style.display = "block";
    } else {
        top.location = self.location;
    }
    </script>
  • 使用X-Frame-Options防止网页被iframe:X-FRAME-OPTIONS是微软提出的一个http头,专门用来防御利用iframe嵌套的点击劫持攻击。
    DENY               // 拒绝任何域加载
    SAMEORIGIN         // 允许同源域下加载
    ALLOW-FROM         // 可以定义允许frame加载的页面地址

如何禁止被使用的 iframe 对当前网站某些操作?

sandbox是html5的新属性,主要是提高iframe安全系数。iframe因安全问题而臭名昭著,这主要是因为iframe常被用于嵌入到第三方中,然后执行某些恶意操作。【这个与上面说到的安全沙箱(Sandbox)不同】 现在有一场景:我的网站需要 iframe 引用某网站,但是不想被该网站操作DOM、不想加载某些js(广告、弹框等)、当前窗口被强行跳转链接等,我们可以设置 sandbox 属性:

  • allow-same-origin:允许被视为同源,即可操作父级DOM或cookie等
  • allow-top-navigation:允许当前iframe的引用网页通过url跳转链接或加载
  • allow-forms:允许表单提交
  • allow-scripts:允许执行脚本文件
  • allow-popups:允许浏览器打开新窗口进行跳转
  • “”:设置为空时上面所有允许全部禁止

总结

到此这篇关于前端常见的安全问题以及防范措施的文章就介绍到这了,更多相关前端常见安全问题及防范内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 安全浏览网页 巧妙防范网页木马侵扰设置方法

    教大家防木马的办法,只针对网页木马,有效率90%以上.可以防止90%以上木马在你的机器上被执行,甚至杀毒软件发现不了的木马都可以禁止执行,先说一下原理. 现在网页木马无非有以下几种方式中到你的机器里: 1.把木马文件改成BMP文件,然后配合你机器里的DEBUG来还原成EXE,网上存在该木马20% : 2.下载一个TXT文件到你机器,然后里面有具体的FTP连接,FTP连上他们有木马的机器下载木马,网上存在该木马20%: 3.也是最常用的方式,下载一个HTA文件,然后用网页控件解释器来还原木马,该木

  • 浅谈web上存漏洞及原理分析、防范方法(安全文件上存方法)

    这类漏洞,主要是可以读取用户传入路径名称,采用不正确的过滤方法,导致恶意用户,将文件上存到非预期的地方,带来安全隐患. 其实,我们抓住几个地方即可,我们先来分析下,既然用户要上存文件,而且文件将是多种多样格式:可能有的文件内容与用户传入格式不一致,有的文件内容还夹杂木马代码. 那么,我们让用户上存文件,跟站点文件做一个分别授权,做隔离. 让保存上存目录独立开来,目录权限只读不能执行这一步从系统设计加以授权,无论你上次什么文件,都不可能执行到.就算我不做任何检测,你的文件都上存到这里了,也不会对我

  • 详解前端安全之JavaScript防http劫持与XSS

    HTTP劫持.DNS劫持与XSS 先简单讲讲什么是 HTTP 劫持与 DNS 劫持. HTTP劫持 什么是HTTP劫持呢,大多数情况是运营商HTTP劫持,当我们使用HTTP请求请求一个网站页面的时候,网络运营商会在正常的数据流中插入精心设计的网络数据报文,让客户端(通常是浏览器)展示"错误"的数据,通常是一些弹窗,宣传性广告或者直接显示某网站的内容,大家应该都有遇到过. DNS劫持 DNS 劫持就是通过劫持了 DNS 服务器,通过某些手段取得某域名的解析记录控制权,进而修改此域名的解析

  • 前端常见的安全问题以及防范措施总结大全

    目录 前言 前端安全问题 跨站脚本攻击(XSS) 反射型XSS攻击 基于DOM的XSS攻击 存储型XSS攻击 这几种XSS攻击类型的区别 XSS防范措施 输入过滤 预防存储型和反射型XSS攻击 预防DOM型XSS攻击 ContentSecurityPolicy 其他措施 XSS攻击案例 跨站请求伪造(CSRF) CSRF是怎么攻击的? 常见的CSRF攻击类型 GET类型的CSRF POST类型的CSRF 链接类型的CSRF CSRF的特点 CSRF防范措施 同源检测 CSRFToken 给Coo

  • 近期服务器出现的安全问题以及防范措施2017.05

    尊敬的用户: 近期境外黑客组织公布了一批Windows高危漏洞及批量利用工具,利用该工具可对开放135/137/139/445端口的Windows服务器执行任意命令,引发包括主机蓝屏.被入侵删除数据等一系列严重后果.微软官方已发布了漏洞补丁,但大量客户尚未修补,风险极大,为了更好的提升服务器和云主机的安全性,请您务必留意以下信息: 针对使用中的windows操作系统服务器,请确认服务器的[135.137.139.445]端口是否开启,这些端口受本次漏洞影响,极易导致服务器被入侵.如果端口有启用,

  • PHP网站常见安全漏洞,及相应防范措施总结

    目前,基于PHP的网站开发已经成为目前网站开发的主流,本文笔者重点从PHP网站攻击与安全防范方面进行探究,旨在减少网站漏洞,希望对大家有所帮助! 一.常见PHP网站安全漏洞 对于PHP的漏洞,目前常见的漏洞有五种.分别是Session文件漏洞.SQL注入漏洞.脚本命令执行漏洞.全局变量漏洞和文件漏洞.这里分别对这些漏洞进行简要的介绍. 1.session文件漏洞 Session攻击是黑客最常用到的攻击手段之一.当一个用户访问某一个网站时,为了免客户每进人一个页面都要输人账号和密码,PHP设置了S

  • 浅谈Android安全风险与防范措施

    做好的apk文件,被检测工具检测出一大堆风险问题,是不是感觉自己的付出白费了,今天咱就聊聊android的安全防范问题. 一,先说安全检查方面的吧 1,源文件安全问题方面 1.1篡改和二次打包风险 1.2应用签名未校验风险 1.3Java代码反编译风险检测 1.4代码未混淆风险检测 1.5资源文件泄露风险检测 2,数据存储安全问题方面 2.1 WebView明文存储密码风险检测 2.2Internal Storage数据全局可读写风险检测 3.3加密算法不安全使用风险 4.4日志数据泄露风险 4

  • 前端常见跨域解决方案(全)

    什么是跨域? 跨域是指一个域下的文档或脚本试图去请求另一个域下的资源,这里跨域是广义的. 广义的跨域: 1.) 资源跳转: A链接.重定向.表单提交 2.) 资源嵌入: <link>.<script>.<img>.<frame>等dom标签,还有样式中background:url().@font-face()等文件外链 3.) 脚本请求: js发起的ajax请求.dom和js对象的跨域操作等 其实我们通常所说的跨域是狭义的,是由浏览器同源策略限制的一类请求场

  • WEB前端常见受攻击方式及解决办法总结

    一个网站建立以后,如果不注意安全方面的问题,很容易被人攻击,下面就讨论一下几种漏洞情况和防止攻击的办法. 一.SQL注入 所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令.具体来说,它是利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句.比如先前的很多影视网站泄露VIP会员密码

  • 详细总结Python常见的安全问题

    一.输入注入 注入攻击非常广泛而且很常见,注入有很多种类,它们影响所有的语言.框架和环境. SQL 注入是直接编写 SQL 查询(而非使用 ORM) 时将字符串字面量与变量混合.可以通过https://www.jb51.net/article/187001.htm 这个链接查看 SQL 注入所有可能发生的复杂方式. 命令注入可能在使用 popen.subprocess.os.system 调用一个进程并从变量中获取参数时发生,当调用本地命令时,有人可能会将某些值设置为恶意值. 下面是个简单的脚本

  • JS前端常见的竞态问题解决方法详解

    目录 什么是竞态问题 取消过期请求 XMLHttpRequest 取消请求 fetch API 取消请求 axios 取消请求 可取消的 promise 忽略过期请求 封装指令式 promise 使用唯一 id 标识每次请求 「取消」和「忽略」的比较 「取消」更实际 「忽略」更通用 总结 什么是竞态问题 竞态问题,又叫竞态条件(race condition),它旨在描述一个系统或者进程的输出依赖于不受控制的事件出现顺序或者出现时机. 此词源自于两个信号试着彼此竞争,来影响谁先输出. 简单来说,竞

  • 2022最新前端常见react面试题合集

    目录 react性能优化方案 什么是 React Context? 何为 JSX props 是什么 应该在 React 组件的何处发起 Ajax 请求 react 强制刷新 使用 React Hooks 好处是啥? Redux内部原理 内部怎么实现dispstch一个函数的 何为纯函数(pure function) 如何配置 React-Router 实现路由切换 在 React 中,何为 state react16版本的reconciliation阶段和commit阶段是什么 类组件和函数组

  • PHP开发中常见的安全问题详解和解决方法(如Sql注入、CSRF、Xss、CC等)

    浅谈Php安全和防Sql注入,防止Xss攻击,防盗链,防CSRF 前言: 首先,笔者不是web安全的专家,所以这不是web安全方面专家级文章,而是学习笔记.细心总结文章,里面有些是我们phper不易发现或者说不重视的东西.所以笔者写下来方便以后查阅.在大公司肯定有专门的web安全测试员,安全方面不是phper考虑的范围.但是作为一个phper对于安全知识是:"知道有这么一回事,编程时自然有所注意". 目录: 1.php一些安全配置(1)关闭php提示错误功能(2)关闭一些"坏

随机推荐