web及APP 部分安全内容分享

最新推荐文章于 2021-04-09 09:13:40 发布

小洁

最新推荐文章于 2021-04-09 09:13:40 发布

阅读量390

点赞数

文章标签： web安全

本文链接：https://blog.csdn.net/lijieeer/article/details/100662819

版权

xss攻击

跨站脚本攻击（xss），英文全称 cross site script,是web安全头号大敌。
XSS攻击，⼀般是指⿊客通过在⽹⻚中注⼊恶意脚本，当⽤户浏览⽹⻚时，恶意脚本执⾏，控制⽤户浏览器⾏为的⼀种攻击⽅式。
举个例子

本地服务器的的/xssTest ⽬录下，有⼀个test.php⽂件，代码如下：

<?php $userName=$_GET['userName']; //获取⽤户输⼊的参数 echo " ".$userName.""; //直接输出⽤户的参数给前端⻚⾯ ?>

当⽤户访问以下URL：http://localhost/xssTest/test.php?userName=jack
我们尝试在URL中插⼊JavaScript代码：
http://localhost/xssTest/test.php?userName=
当⽤户访问这个URL：便会打开百度首页

XSS攻击的基本类型

• 反射型XSS攻击

⾮持久性XSS,这种攻击⽅式把XSS的Payload写在URL中，通过浏览器直接“反射”给⽤户。这种攻击⽅式通常需要诱使⽤户点击某个恶意链接，才能攻击成功。

• 储存型XSS攻击
持久性XSS,会把⿊客输⼊的恶意脚本存储在服务器的数据库中。当其他⽤户浏览⻚⾯包含这个恶意脚本的⻚⾯，⽤户将会受到⿊客的攻击。⼀个常⻅的场景就是⿊客写下⼀篇包含恶意JavaScript脚本的博客⽂章，当其他⽤户浏览这篇⽂章时，恶意的JavaScript代码将会执⾏。

• DOM Based XSS
是⼀种利⽤前端代码漏洞进⾏攻击的攻击⽅式。前⾯的反射型XSS与存储型XSS虽然恶意脚本的存放位置不同，但其本质都是利⽤后端代码的漏洞。
反射型和存储型xss是服务器端代码漏洞造成的，payload在响应⻚⾯中，DOM Based中，payload不在服务器发出的HTTP响应⻚⾯中，当客户端脚本运⾏时（渲染⻚⾯时），payload才会加载到脚本中执⾏。

XSS的危害

我们把进⾏XSS攻击的恶意脚本成为XSS Payload。XSS Payload的本质是JavaScript脚本，所以JavaScript可以做什么，XSS攻击就可以做什么。
⼀个最常⻅的XSS Payload就是盗取⽤户的Cookie,从⽽发起Cookie劫持攻击。Cookie中，⼀般会保存当前⽤户的登录凭证，如果Cookie被⿊客盗取，以为着⿊客有可能通过Cookie直接登进⽤户的账户，进⾏恶意操作。

XSS防御

• HttpOnly
最早是由微软提出，并在IE6中实现的，⾄今已逐渐成为⼀个标准。浏览器将禁⽌⻚⾯的JavaScript访问带有HttpOnly 属性的Cookie。
⼀个Cookie的使⽤过程如下：
Step1: 浏览器向服务器发送请求，这时候没有cookie。
Step2: 服务器返回同时，发送Set-Cookie头，向客户端浏览器写⼊Cookie。
Step3: 在该Cookie到期前，浏览器访问该域名下所有的⻚⾯，都将发送该Cookie。
⽽HttpOnly是在Set-Cookie时标记的。

• 输⼊检查
常⻅的Web漏洞，如XSS、SQL注⼊等，都要求攻击者构造⼀些特殊的字符串，⽽这些字符串是⼀般⽤户不会⽤到的，所以进⾏输⼊检查就很有必要了。
输⼊检查可以在⽤户输⼊的格式检查中进⾏。很多⽹站的⽤户名都要求是字⺟及数字的组合如“abc1234”，其实也能过滤⼀部分的XSS和SQL注⼊。但是，这种在客户端的限制很容易被绕过，攻击者可以⽤JavaScript或⼀些请求⼯具，直接构造请求，想⽹站注⼊XSS或者SQL。所以，除了在客户端进⾏格式检查，往往还需要在后端进⾏⼆次检查。客户端的检查主要作⽤是阻挡⼤部分误操作的正常⽤户，从⽽节约服务器资源。

• 输出转义
在输出数据之前对潜在的威胁的字符进⾏编码、转义是防御XSS攻击⼗分有效的措施。
为了对抗XSS,在HtmlEncode中⾄少转换以下字符：

< 转成 <

转成 >
& 转成 &
“ 转成 "
‘ 转成 &#39

CSRF攻击

• 名词释义
CSRF全称为跨站请求伪造（Cross-site request forgery），是⼀种⽹络攻击⽅式，也被称为 one-click attack 或者 session riding。
• 攻击原理
CSRF攻击利⽤⽹站对于⽤户⽹⻚浏览器的信任，挟持⽤户当前已登陆的Web应⽤程序，去执⾏并⾮⽤户本意的操作。

举个例子
1.用户登录、浏览并信任正规网站WebA，同时，WebA通过用户的验证并在用户的浏览器中产生Cookie。
在这里插入图片描述
2.攻击者WebB通过在WebA中添加图片链接等方式诱导用户User访问网站WebB。

3.在用户User被诱导访问WebB后，WebB会利用用户User的浏览器访问第三方网站WebA，并发出操作请求

4.用户User的浏览器根据WebB的要求，带着步骤一中产生的Cookie访问WebA。
在这里插入图片描述
5.网站WebA接收到用户浏览器的请求，WebA无法分辨请求由何处发出，由于浏览器访问时带上用户的Cookie，因此WebA会响应浏览器的请求，如此一来，攻击网站WebB就达到了模拟用户操作的目的。

CSRF防御

• 只是⽤JSON_API
使⽤JavaScript发起AJAX请求是限制跨域的，并不能通过简单的表单来发送JSON，所以，通过只接收JSON可以很⼤可能避免CSRF攻击。

• 验证HTTP Referer 字段
• 根据 HTTP 协议，在 HTTP 头中有⼀个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问⼀个安全受限⻚⾯的请求来⾃于同⼀个⽹站，⽐如⽤户User想要在⽹站WebA中进⾏转账操作，那么⽤户User
◦ 必须先登录WabA
◦ 然后再通过点击⻚⾯上的按钮出发转账事件
这时该转帐请求的 Referer 值就会是转账按钮所在的⻚⾯的URL，⽽如果⿊客要对银⾏⽹站实施 CSRF攻击，他只能在他⾃⼰的⽹站构造请求，当⽤户User通过⿊客的⽹站发送请求到WebA时，该请求的 Referer 是指向⿊客⾃⼰的⽹站。因此，要防御 CSRF 攻击，⽹站WebA只需要对于每⼀个转账请求验证其 Referer 值，如果是以⽹站WebA的⽹址开头的域名，则说明该请求是来⾃WebA⾃⼰的请求，是合法的。如果 Referer 是其他⽹站的话，则有可能是⿊客的 CSRF 攻击，拒绝该请求。

• Token
CSRF 攻击之所以能够成功，是因为⿊客可以完全伪造⽤户的请求，该请求中所有的⽤户验证信息都是存在于 cookie 中，因此⿊客可以在不知道这些验证信息的情况下直接利⽤⽤户⾃⼰的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放⼊⿊客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加⼊⼀个随机产⽣的 token，并在服务器端建⽴⼀个拦截器来验证这个token，如果请求中没有 token 或者 token 内容不正确，则认为可能是CSRF 攻击⽽拒绝该请求。
这种⽅法要⽐检查 Referer 要安全⼀些，token 可以在⽤户登陆后产⽣并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进⾏⽐对。

APP安全初涉

hock与反编译

• 打包的过程就是加密的过程
• hock是⼀种反编译的⼿段

APP混淆

• 1.随机码后缀（#define class sdfwesxce$sd）
• 2.密码本转义 (a=z z=a)
• 3.⾁鸡⽅法（function getPassWord{}）

其他安全事项

• 1. 内存安全缓存安全
• 2. 传输安全
• 3. 提⾼加密⻔槛
• 4. 业务安全

参考信息：
https://www.cnblogs.com/stefanieszx11/p/8602138.html
https://wenku.baidu.com/view/
b1fd7b22ad51f01dc381f192.html
https://wenku.baidu.com/view/
ac62af76591b6bd97f192279168884868662b859.html