应用安全
漏洞
代码漏洞
XSS脚本注入
XSS攻击是Web攻击中最常见的攻击方法之一，它是通过对网页注入可执行代码且成功地被浏览器执行，达到攻击的目的，形成了一次有效XSS攻击，一旦攻击成功，它可以获取用户的联系人列表，然后向联系人发送虚假诈骗信息，可以删除用户的日志等等，有时候还和其他攻击方式同时实施比如SQL注入攻击服务器和数据库、Click劫持、相对链接劫持等实施钓鱼，它带来的危害是巨大的，是web安全的头号大敌。
XSS攻击能做什么？
1、Cookie劫持
利用浏览器插件，可以获取请求中的Cookie信息，从获取到的Cookie信息中，读取用户的私密信息。
2、模拟GET、POST请求操作用户的浏览器。使用JavaScript模拟浏览器发包
“Cookie劫持”失效时，或者目标用户的网络不能访问互联网等情况下，这种方式非常有用
3、XSS钓鱼
利用JavaScript在当前页面“画出”一个伪造的登录框，当用户在登录框中输入用户名与密码后，其密码将被发送到黑客的服务器
4、获取用户浏览器信息
JavaScript脚本通过XSS读取浏览器的UserAgent对象来识别浏览器的版本。alert(navigator.userAgent)
通过JavaScript脚本区分浏览器之间的实现差异
5、识别用户安装的软件
通过查询某些属性是否存在，从而判断是否安装了某个软件或某个插件
6、通过CSS，来发现用户曾经访问过的网站
通过style的visited属性，来判断链接是否被访问
7、劫持浏览器会话，从而执行任意操作，如进行非法转账、强制发表日志、发送电子邮件等
8、强制弹出广告页面，刷流量等
9、进行大量的客户端攻击，如DDoS攻击
10、获取用户电脑的真实IP
我们项目中之前也遇到了XSS脚本注入，但那时候不知道这个专业名词，直到上周一个技术论坛分享了这个名字的解释之后才知道。我们在前台页面输入框中输入<script>alert(111)</script>，在读取该界面内容是出现弹窗，当然这只是无恶意的测试。我们的处理方式是过滤像<和>这种类型的字符，当然也可以进行转义，具体看项目需求了。
CSRF跨站请求伪造
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证（表单令牌验证）；在 HTTP 头中自定义属性并验证。
1、尽量使用POST，限制GET
GET接口太容易被拿来做CSRF攻击，看第一个示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。接口最好限制为POST使用，GET则无效，降低攻击风险。（get和post区别：https://blog.csdn.net/qq_42806764/article/details/86596589?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param)当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样就增加暴露的可能性。
2、加验证码
验证码，强制用户必须与应用进行交互，才能完成最终请求。在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
3、Referer Check
Referer Check在Web最常见的应用就是“防止图片盗链”。同理，Referer Check也可以被用于检查请求是否来自合法的“源”（Referer值是否是指定页面，或者网站的域），如果都不是，那么就极可能是CSRF攻击。但是因为服务器并不是什么时候都能取到Referer，所以也无法作为CSRF防御的主要手段。但是用Referer Check来监控CSRF攻击的发生，倒是一种可行的方法。
4 、Anti CSRF Token
现在业界对CSRF的防御，一致的做法是使用一个Token（Anti CSRF Token）。
例子：
用户访问某个表单页面。服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。在页面表单附带上Token参数。用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
这一块目前项目中没遇到过，读懂了大概的意思，有机会会去尝试复现。
SQL注入
SQL注入比较常见，举个例子：
执行一条sql，如下：
String sql = "select * from user_table where username =
' "+userName+" ' and password =' "+password+" '"
–当输入了上面的用户名和密码（or 1 = 1, 123456），上面的SQL语句变成：
SELECT * FROM user_table WHERE username = or 1 = 1 and password= 123456
此时这条sql无论如何都会成功执行，成功绕过了用户名和密码校验并获取到了数据库中的信息，甚至还可以删除或者操作数据库中的数据。
这个sql例子是很常见的一个问题，同时目前在公司中开发都采用比较成熟的框架进行开发，所以基本不会碰见此类问题，但是如何在mybatis的框架下成功进行sql注入？
那就是参数获取用${param}，我们之前在项目中许多地方都用了${param}获取参数值，后面发现了会出现sql注入的问题，而#{param}可以很好的避免这一问题。
明文传输
明文的意思就是没有加密的文本。例如http协议，我们常访问的http网站就是明文传输，如果被抓包那就直接暴露里面的信息，因为没有加密，所以非常不安全，目前越来越多的网站使用https，s就是safe安全的意思，也就是https协议在传输的过程是加密的，这样就安全很多了。现在有的浏览器打开http网站直接就说网站不安全就是这个原因。我们项目是用的base64加密方式，可能也不是很安全，还需要进一步的加强，关于登录和安全这一块没怎么接触过，学习过后再来补充。
越权
数据越权
找了一圈资料，关于数据越权的很少，但是搜到了一些资料，关于水平越权的，数据越权应该也叫水平越权吧。水平越权也可以把其称作访问控制攻击漏洞。Web应用程序在接收到用户的请求时，我们在增删改查某条数据时候，没有判断数据所对应的用户，或者在判断数据的用户时是通过从用户表单参数中获取userid来实现的，这里的话我们可以修改userid来实现水平越权。
功能越权
垂直越权又叫做权限提升攻击，具体原因就是web应用没有做用户权限控制，或者只是在菜单上做了权限控制，导致恶意用户只要猜测到其他管理页面的URL，就可以访问或者控制其他角色拥有的数据或者页面，达到权限提升的目的。这一块目前项目中还没做，但在后续工作安排中会实现，待补充。
错误日志输出
由于时间关系分享人没做分享，个人猜测是日志输出级别设置相关的。
URL注入
URL注入攻击与XSS跨站、SQL注入类似，也是参数可控的一种攻击方式。URL注入攻击的本质就是URL参数可控。攻击者可通过篡改URL地址，修改为攻击者构造的可控地址，从而达到攻击的目的。
登录错误次数未做控制
主要是为了防止运用工具暴力破解，在日常生活中已经很常见了。
登陆、提交页面未加入验证码或验证短信
也是为了防暴力破解，有效bai防止这种问题对某一du个特定注册用户用特定程序暴力破解方zhi式进行不断的登陆尝试。
弱口令
密码简单容易被破解，如：名字+生日。常见的弱口令分为默认型弱口令和社工型弱口令。对于我们普通用户来说，主要是社工型弱口令。
文件上传漏洞
大部分的网站和应用系统都有上传功能，一些文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，导致允许攻击者向某个可通过Web访问的目录上传任意PHP文件，并能够将这些文件传递给PHP解释器，就可以在远程服务器上执行任意PHP脚本。
当系统存在文件上传漏洞时攻击者可以将病毒，木马，WebShell，其他恶意脚本或者是包含了脚本的图片上传到服务器，这些文件将对攻击者后续攻击提供便利。根据具体漏洞的差异，此处上传的脚本可以是正常后缀的PHP，ASP以及JSP脚本，也可以是篡改后缀后的这几类脚本。
上传文件是病毒或者木马时，主要用于诱骗用户或者管理员下载执行或者直接自动运行；
上传文件是WebShell时，攻击者可通过这些网页后门执行命令并控制服务器；
上传文件是其他恶意脚本时，攻击者可直接执行脚本进行攻击；
上传文件是恶意图片时，图片中可能包含了脚本，加载或者点击这些图片时脚本会悄无声息的执行；
上传文件是伪装成正常后缀的恶意脚本时，攻击者可借助本地文件包含漏洞(Local File Include)执行该文件。如将bad.php文件改名为bad.doc上传到服务器，再通过PHP的include，include_once，require，require_once等函数包含执行。
此处造成恶意文件上传的原因主要有三种：
文件上传时检查不严。没有进行文件格式检查。一些应用仅仅在客户端进行了检查，而在专业的攻击者眼里几乎所有的客户端检查都等于没有检查，攻击者可以通过NC，Fiddler等断点上传工具轻松绕过客户端的检查。一些应用虽然在服务器端进行了黑名单检查，但是却可能忽略了大小写，如将.php改为.Php即可绕过检查；一些应用虽然在服务器端进行了白名单检查却忽略了%00截断符，如应用本来只允许上传jpg图片，那么可以构造文件名为xxx.php%00.jpg,其中%00为十六进制的0x00字符，.jpg骗过了应用的上传文件类型检测，但对于服务器来说，因为%00字符截断的关系，最终上传的文件变成了xxx.php。
文件上传后修改文件名时处理不当。一些应用在服务器端进行了完整的黑名单和白名单过滤，在修改已上传文件文件名时却百密一疏，允许用户修改文件后缀。如应用只能上传.doc文件时攻击者可以先将.php文件后缀修改为.doc，成功上传后在修改文件名时将后缀改回.php。
使用第三方插件时引入。好多应用都引用了带有文件上传功能的第三方插件，这些插件的文件上传功能实现上可能有漏洞，攻击者可通过这些漏洞进行文件上传攻击。如著名的博客平台WordPress就有丰富的插件，而这些插件中每年都会被挖掘出大量的文件上传漏洞。
敏感信息泄露
JavaScript作为一种相当简单但功能强大的客户端脚本语言，本质是一种解释型语言。所以，其执行原理是边解释边运行。上述特性就决定了JavaScript与一些服务器脚本语言（如ASP、PHP）以及编译型语言（如C、C++）不同，其源代码可以轻松被任何人获取到。一些粗心的开发者将各式敏感信息存储在JavaScript脚本中，由于JS的特性，攻击者可以对这些信息一览无余，从而导致对WEB服务和用户隐私造成不同程度的威胁。
目录遍历
一. 什么是目录遍历漏洞
目录遍历（路径遍历）是由于web服务器或者web应用程序对用户输入的文件名称的安全性验证不足而导致的一种安全漏洞，使得攻击者通过利用一些特殊字符就可以绕过服务器的安全限制，访问任意的文件（可以使web根目录以外的文件），甚至执行系统命令。
二. 目录遍历漏洞原理
程序在实现上没有充分过滤用户输入的…/之类的目录跳转符，导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
三. 目录遍历漏洞实例
读取文件的url：
http://www.test.com/my.jsp?file=abc.html
恶意url:
http://www.test.com/my.jsp?file=…/…/Windows.system.ini
四. 目录遍历漏洞的防御
1.对用户的输入进行验证，特别是路径替代字符“…/”
2.尽可能采用白名单的形式，验证所有输入
3.合理配置web服务器的目录权限
4.程序出错时，不要显示内部相关细节
五.出现场景
出现在文件读取或者展示图片等对文件读取交互的功能块。
总结：对照着一个个的点，我发现许多问题在我目前项目中都存在，说明对于web安全这块我们还有许多工作要做，这可能也是目前许多中小型互联网公司项目的弊端，还不够注重安全这一块。希望在接下来的工作中我可以和团队一起完善安全这一块。