因而这些都可以认为是系统中存在的安全漏洞。session默认过期时间是30分钟而我一直在请求后台，session是不可能失效的。中间页面是iframe，是一个系统。现在我们就找为啥请求的时候不将Cookie发送给后台，知道了为啥不发送也就知道了问题所在。然后我发现了问题所在，第一次打开请求B系统的页面B系统会响应给浏览器一个key为JSESSIONID的Cookie，因为这个浏览器第一次请求B系统。如果我不懂Cookie的作用域和端口没关系肯定找不到原因所在。
漏洞是在硬件、软件、协议的具体实现或系统安全策略上存在的缺陷，从而可以使攻击者能够在未授权的情况下访问或破坏系统。具体举例来说，比如在Intel Pentium芯片中存在的逻辑错误，在Sendmail早期版本中的编程错误，在NFS协议中认证方式上的弱点，在Unix系统管理员设置匿名Ftp服务时配置不当的问题都可能被攻击者使用，威胁到系统的安全。因而这些都可以认为是系统中存在的安全漏洞。bug狭义的概念是指软件程序漏洞或缺陷，广义的概念还包括测试工程师或用户所发现和提出的软件可更改的细节、或与需求文档存在差异的功能实现等。
简单点说就是 程序不按照你的预期执行，或者程序直接报错了。在每个程序员的职业生涯中都会碰到或多或少的bug，有人写的程序bug就是少，有人写的程序bug就是很多。这是因为每个人的对技术的广度和深度都不同。知道技术的原理写起来代码肯定bug会少些，不懂原理写起来肯定错误百出。但是即便你精通各种技术还是会出现bug，这是不可避免的。
对待BUG的态度我见过无数程序员一看到程序出错了就很紧张，仿佛报错要他命似的。乱了阵脚，其实报错不可怕，报错都是可以处理的。你看到哪里报错找哪里，找到哪一行想想哪一行为啥会报错。直接debug不就可以了。报错没事，心态放平慢慢找，一点一点debug，找到为什么报错就可以了。其实做久了才知道，报错的bug一点都不可怕，不报错的bug才可怕，逻辑完全正确，但就是不按照你预期的走。这种bug往往搞得你怀疑人生。
如何找BUG找bug的前提是复现问题，很多bug都是在特定的情况下才会出现的，就像我们经常碰到的在自己电脑上没问题在别人电脑上就有问题，或者在外网环境没问题，在内网环境就不行。我们碰到这种情况要第一时间复现问题，如果复现不了问题你肯定解决不了。切记不能自己闷着头瞎调试。你的环境没问题你还在你电脑上调试，能调试出来才怪了。你要去有问题的环境找问题，内网有毛病你就去内网复现问题，复现了再比较和外网有啥区别慢慢解决，切不可产生畏战心理，其实好多问题只要找到根源就豁然开朗了。
一个不太好找的BUG去年冬天公司安排我去哈尔滨培训，培训前我们把要培训的功能测试了一遍，其他有问题的很快改了，偏偏我就遇到了一个问题，有一个接口请求后台，后台从Session里面拿数据，但是后台的session对象一直为null，这就让人很费解。session默认过期时间是30分钟而我一直在请求后台，session是不可能失效的。我在本地怎么测怎么没问题。先说一下我们的环境，开发的时候我们是前端一个项目后端一个项目，前端系统配置菜单，前端直接请求后端拿数据。而我们发布后就成了，前端加页面需要去另一个系统加，另一个系统是一套.net的系统，我们在.net系统里面配置前端页面地址，菜单名，权限等。经常做后台管理系统的同学应该知道一般是上边一栏菜单，左边一栏菜单。中间是功能页面。中间页面是iframe，是一个系统。而我们就不一样了，上边和左边的菜单栏是一个系统，中间的功能页是嵌的我们前端系统的页面地址，中间功能页也是iframe。开始我感觉和这些没问题，既然功能页都是iframe应该没区别。但是我在本地怎么也复现不了。这就很无奈，找bug你一定要找到蛛丝马迹。我就看前端页面发送的请求，看了半天才发现问题。
我们看响应头有一个 Set-Cookie 这里给浏览器了一个Cookie 。看似没啥毛病，但是我发现每一次请求后端都会给浏览器一个key为JSESSIONID的Cookie，而且每次请求时请求头都不会把这个Cookie发送到后台。这就让人很费解。这样我也就明白了为啥后台用Session对象的时候为null了。现在我们就找为啥请求的时候不将Cookie发送给后台，知道了为啥不发送也就知道了问题所在。后台给浏览器Cookie的时候别的都挺正常的但是SameSite=lax这个东西我看不懂。
经过我的百度查到了问题知道了这个属性是啥意思。
简单点来说就是谷歌为了安全性，在浏览器80版本以后就不允许不同站点的原页面和iframe页面请求时发送Cookie，因为我们内网发布的菜单栏和iframe是俩系统也就是俩站点，所以iframe的页面发送的请求都不带着Cookie，自然也就导致后台拿不到Session了。而外网开发环境菜单栏和iframe是一个系统所以iframe页面发送的请求都带着cookie，也就不会导致后台取不到Session了。至此我们发现问题所在。接着想办法解决就可以了。
其实这个BUG讲出来看似很简单，其实不然，首先你要复现问题，其次你一定要知道Session和Http协议的工作原理，如果你不懂这俩技术的原理是肯定找不到问题所在的。
系统不存在一会行一会不行还有一个问题，就是我们一台服务器上部署了两个后台系统，一个是A系统占用80端口，一个是B系统占用8080端口。有些前端页面请求了A系统的后台，有些前端页面请求了B系统的后台。别人给我反映经常丢Session(也就是上面说的后台拿不到Session对象)一会好使一会不好使，好几个人都没找到咋回事，找到我了，其实我也很懵。但是我不认同别人的说法，系统绝对不存在一会可以一会不可以，可以的时候一定有可以的原因，不可以的时候一定有不可以的原因。有因必有果。经过我的测试如果一直使用请求A系统的页面是没问题的，一直使用请求B系统的页面也是可以的。但是打开过请求B系统的页面再打开请求A系统的页面必报错。然后我发现了问题所在，第一次打开请求B系统的页面B系统会响应给浏览器一个key为JSESSIONID的Cookie，因为这个浏览器第一次请求B系统。但是JSESSIONID的Path属性为/ 而且Cookie作用域和端口没关系，如果这时候我们打开请求A系统的页面也会把这个JSESSIONID带过去，而这个值和A系统没关系，A系统也就会重新给浏览器一个JSESSIONID，自然A系统也就拿不到Session了。出现BUG第一步一定是要复现，如果复现不了肯定找不到，其次要找痕迹想办法找到哪里不正常，懂原理。如果我不懂Cookie的作用域和端口没关系肯定找不到原因所在。
如果喜欢本篇文章不妨关注点赞收藏，有什么困惑欢迎评论。
原文链接：https://www.cnblogs.com/jidiqi/p/15562213.html
作者：接地气程序员
