咳咳，我又回来水文章了，收文章，收破文章，旧文章，改文章了！（当然是改我自己的文章），计网作业，都是网上的东西整合的，时间有点久了，出处大概标不出来了，看看就行！
文章有什么问题留言告我，对不起！给网络安全 丢人了。
网络安全问题一直是我们在网络通信中探讨的一个话题，请以本学期所学习内容为基础，列举至少3个安全问题，剖析原因并给出解决方案，以此撰写学习报告，不少于3000字。
具体要求： （1）以附件形式提交文档； （2）鼓励录制演示视频，模拟安全问题并从实践上予以解决。
HTTP请求走私
不同服务器分割请求的标准不一样，对同一段tcp内容，前后端服务器获取到的http请求个数不一致，（这里是因为http1.0版本之前，是客户端向服务器每进行一次HTTP请求，都要跟服务器建立一次TCP连接，但这样会对服务器负载开销过大。所以在HTTP1.1版本，增加了新的请求头Connection=Keep-Alive.这种连接会告诉服务器在进行完这一次http请求后不要关闭链接，对于后面的请求还会用这个链接，这样可以提高效率。）解析http数据包时出现差异，就导致了请求走私。
由于HTTP规范提供了两种不同的方法来指定HTTP消息的长度，因此单个消息可能会同时使用这两种方法，如果前端服务器和后端服务器相对于（可能是混淆的）Transfer-Encoding标头而言行为不同，则它们可能在连续请求之间的边界上存在分歧，从而导致请求走私漏洞。
剖析原因：
Content-Length：正常post请求，会带上请求体，请求体有多长，Content-Length的值就是多少字段来判断请求体的内容长度。解析到这个长度位置后，后面的将会舍弃。Transfer-Encoding：字段来判定请求体的结束位置。它不靠Content-Length来告诉web服务器请求体有多长，而是靠0这个字符来代表分块结束，之后还要换行2次。，就是分块传输的标志，以/r/n/r/n代表结束。剩下的将会舍弃。简称TE。如果用户向目标网站发送一个HTTP请求，然后这个请求由反向代理服务器转发，这里有WAF，如果用户绕过这个WAF就是走私。
如果将TE和CL两个放在一块，出现了差异，就出现了五种HTTP请求走私。
解决方案：
禁用代理服务器和后端服务器之间的TCP连接重用(但这样会加大服务器的压力)。使用HTTP/2协议。前后端服务器配置相同。严格的实现RFC7230-7235中所规定的的标准。
模拟安全问题和实践(靶场：Web Application Security, Testing, & Scanning - PortSwigger（在线靶场）、使用软件：Burp Suite)：
HTTP请求走私攻击大致分为三种，CL.TE、TE.CL、TE.TE，这里仅仅举一个例子：
第一次抓包：
第二次抓包：
CL-TE请求方式
前端是CL，后端服务器是TE. 我们设置的CL长度是9，第一个0算一个字符，然后\r\n属于两个字符，0/r/n/r/nqwer就是9个字符，到er截止，无丢弃。然后TE遇到\r\n就截止，qwer就在这次请求中不会出现，当再次请求的话，他就会出现在第二次请求的开头。所以我们第二次请求的时候（点击两次发送），长度还是9的时候，qwer就会出现；
流程：改GET / HTTP/1.1然后，在尾部添加
Content-Length: 9
Transfer-Encoding: chunked
0
Qwer
最后在发包。
CSRF漏洞
CSRF全称为跨站请求伪造（Cross-Site Request Forgery），也被称为 one-click attack 或者 session riding，即跨站请求伪造攻击。是一种网络攻击方式，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成。
剖析原因：
如何确认一个web系统存在CSRF漏洞：
1.对目标网站增删改的地方进行标记，并观察其逻辑，判断请求是否可以被伪造
例如修改管理员账号时，不需要验证旧密码，导致请求容易被伪造；对于敏感信息的修改并没有使用安全的token验证，导致请求容易被伪造
2.确认凭证的有效期
虽然退出或关闭了浏览器，但cookie仍然有效，或者session并没有过期，导致CSRF攻击变得简单
具体描述：
1、用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
2、在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
3、用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
4、网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
5、浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。
解决方案：
1.增加token验证∶对关键操作增加token参数，token值必须随机，每次都不一样;关于安全的会话管理（避免会话被利用广:不要在客户端端保存敏感信息（比如身份认证信息）;测试直接关闭，退出时，的会话过期机制;设置会话过期机制，比如15分钟内无操作，则自动登录超时;
2.访问控制安全管理︰敏感信息的修改时需要对身份进行二次认证，比如修改账号时，需要判断旧密码;敏感信息的修改使用post，而不是get (在服务端区严格区分好POST与GET的数据请求)
3.通过http头部中的referer来限制原页面,增加验证码∶一般用在登录（防暴力破解），也可以用在其他重要信息操作的表单中（需要考虑可用性)
到此不得不提一下xss
xss跨站攻击
跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets,CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户目的。XSS的威力主要是取决于JavaScript能够实现的程度，XSS跨站脚本的形成原因是对输入输出没有严格过滤，导致在页面上可以执行JavaScript等客户端代码，所以只要将敏感字符过滤，就可以修复XSS跨站漏洞。
一般XSS可以分为如下几种常见类型：反射性XSS;存储型XSS;DOM型XSS;
剖析原因：
XSS漏洞的主要原因是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入;
输出转义：根据输出点的位置对输出到前端的内容进行适当转义;
使用手工检测Web应用程序是否存在XSS漏洞时，最重要的是考虑那里有输入，输入的数据在什么地方输出。所以一定要选择有特殊意义的字符，这样可以快速测试是否存在XSS。
（1）在目标站点上找到输入点,比如查询接口,留言板等;
（2）输入一组”特殊字符+唯一识别字符”,点击提交后,查看返回的源码,是否有做对应的处理;
（3）通过搜索定位到唯一字符,结合唯一字符前后语法确认是否可以构造执行js的条件(构造闭合);提交构造的脚本代码,看是否可以成功执行,如果成功执行则说明存在XSS漏洞;
解决方案：
1.在cookie中设置了HttpOnly属性，那么通过JavaScript脚本将无法读取到cookie信息，这样能一定程度上防止XSS攻击。
2.假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的cookie中的变量，HTTP请求头部中的变量等。
3.不仅验证数据的类型，还要验证其格式、长度、范围和内容
4.过滤“<” 、“>” 将用户输入放入引号间，基本实现数据与代码隔离；过滤双引号防止用户跨越许可的标记，添加自定义标记；过滤TAB和空格,防止关键字被拆分；过滤script关键字；过滤&##,防止HTML属性绕过检查。在客户端和服务器端同时做数据的验证与过滤。
5.对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
CSRF看起来好像和XSS跨站脚本是两个不同维度的情况。从名字上来看，同为跨站攻击，XSS攻击是跨站脚本攻击，CSRF攻击是请求伪造，也就是CSRF攻击本不是出自用户之手，却经过第三方恶意攻击者的处理，伪装成了受信任用户。XSS是实现CSRF的诸多途径中的一条，但并不是唯一的一条。
模拟安全问题和实践（靶场：phpstudy下搭建的pikachu靶场（本地靶场）、使用软件：Burp Suit）：
CSRF漏洞：靶场涉及CSRF(get)、CSRF(post)、CSRF Token这里仅仅挑选一个进行说明。
点击修改个人信息进入修改界面点击submit进行修改,发现url没有变化，点击提交之后就跳转到上图这个显示个人信息的页面了，信息修改成功,使用burpsuit进行抓包修改，在提交修改个人信息的时候，可以抓包，看到下面的内容.
在lili登录状态下,这个链接里面是不包含用户名的，试试改一改上面的链接，被攻击者此时的登录状态或cookie/session没有过期，则的信息被修改。
xss跨站攻击:靶场涉及较多，这里仅仅挑选一个进行说明。
直接用js协议，查看网页源代码，发现左右尖括号和单引号都被html编码了，这样闭合标签或者闭合属性都行不通
W3School中对<a>标签的href属性有以下描述：浏览器会尝试检索并显示 href 属性指定的 URL 所表示的文档，或者执行 JavaScript 表达式、方法和函数的列表。
利用JavaScript协议，输入：javascript:alert(12)
注意：
1.这里的每个关卡都存在提示。
2.抓不到本地靶场包
通过局域网的ip地址访问本地靶场即可，(ipconfig)查到局域网IPv4地址,接着访问192.168.XXX.X/pikachu即可。
