首先比较常见的前端的安全性问题就是跨站脚本攻击#xff08;XSS#xff09;。

跨站请求伪造#xff08;csrf#xff…提到这个我可能想到的就是不要暴露太多的账号密码信息。

一些页面的请求和操作要加上权限。

首先比较常见的前端的安全性问题就是跨站脚本攻击XSS。

跨站请求伪造csrf

跨站脚本攻击XSS

攻击者通过在目标网站上注入恶意脚本使之在用户的浏览器上运行。

利用这些恶意脚本攻击者可获取用户的敏感信息如

Cookie、SessionID

脚本长期保存在服务端数据库中用户一旦访问相关页面数据恶意脚本就会被执行。

常见于搜索、微博、社区贴吧评论等。

2011年新浪微博曾被黑客

攻击黑客诱导用户点击一个带有诱惑性的链接便会自动发送一条带有同样诱惑性链接微博。

攻击范围层层扩大也是一种蠕虫攻击。

XSS攻击主要有两大步骤

.innerHTML、.outerHTML、document.write()

HTML

location、onclick、onerror、onload、onmouseover

href

eval()、setTimeout()、setInterval()

等都能把字符串作为代码运行。

如果不可信的数据拼接到字符串中传递给这些

W3C

属性禁止JavaScript读取cookie验证码防止脚本冒充用户提交危险操作。

跨站请求伪造CSRF

攻击者诱导受害者进入第三方网站在第三方网站中向被攻击网站发送跨站请求。

利用受害者在被攻击网站已经获取的注册凭证绕过后台的用户验证达到冒充用户对被攻击的网站执行某项操作的目的。

攻击者引诱受害者访问B网站

srchttp://bank.example/withdraw?amount10000forhacker

在受害者访问含有这个img的页面后浏览器会自动向http://bank.example/withdraw?accountxiaomingamount10000forhacker发出一次HTTP请求。

bank.example就会收到包含受害者登录信息的一次跨域请求

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

form

actionhttp://bank.example/withdraw

methodPOST

攻击一般发起在第三方网站而不是被攻击的网站。

被攻击的网站无法防止攻击发生。

攻击利用受害者在被攻击网站的登录凭证冒充受害者提交操作而不是直接窃取数据。

整个过程攻击者并不能获取到受害者的登录凭证仅仅是“冒用”。

解决办法:

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

表单请求携带CSRF

其实就是服务器生成的随机字符串然后将该字符串植入到返回的页面中通常是放到表单的隐藏输入框中这样能够很好的保护

CSRF

点击劫持Clickjacking是一种通过视觉欺骗的手段来达到攻击目的手段。

往往是攻击者将目标网站通过

iframe

为透明的使得肉眼不可见这样一来当用户在攻击者的网站中操作的时候比如点击某个按钮这个按钮的顶层其实是

解决办法

theBodydocument.getElementByTagName(body)[0];

}else{

让用户自动转入自己开发的网站。

而很多用户却往往无法察觉到自己已经被劫持。

其实验证被劫持的方法就是输入任何网址看看所打开的网页是否和自己输入的网址一致

解决办法

值分成两个部分第一部分指定哈希值的生成算法sha256、sha384

base64

编码的实际哈希值两者之间通过一个短横-分割。

integrity

值可以包含多个由空格分隔的哈希值只要文件匹配其中任意一个哈希值就可以通过校验并加载该资源。

开启

SRI

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

解决办法

对用户进行分级管理严格控制用户的权限对于普通用户禁止给予数据库建立、删除、修改等相关权限只有系统管理员才具有增、删、改、查的权限。

2、参数传值

在书写SQL语言时禁止将变量直接写入到SQL语句必须通过设置相应的参数来传递相关的变量。

从而抑制SQL注入。

数据输入不能直接嵌入到查询语句中。

同时要过滤输入的内容过滤掉不安全的输入数据。

或者采用参数传值的方式传递输入变量。

这样可以最大程度防范SQL注入攻击。