本文目录一览：
- 1、有什么 绕过 htmlentities 进行 xss 攻击的方法吗
- 2、web攻击有哪些？怎么防护？
- 3、xss包搭配localstorage可以预防xss攻击么
- 4、SpringBoot 防止SQL注入、XSS攻击、CSRF/CROS恶意访问
- 5、XSS攻击原理是什么？
- 6、asp.net如何防止xss(脚本注入啊)
有什么 绕过 htmlentities 进行 xss 攻击的方法吗
函数：htmlentities(string,quotestyle,character-set)
参数二是可选的。
规定如何编码单引号和双引号。
ENT_COMPAT - 默认。仅编码双引号或不成对的单引号。
ENT_QUOTES - 编码双引号和单引号。
ENT_NOQUOTES - 不编码任何引号。
参数三也可选的，是转换的字符集类型。
有这么一种情形：当我们使用这个函数的时候，使用了参数二。设置了过滤掉双引号很单引号这些东西（或许不编码）就容易出现XSS。
如：
?php
echo htmlspecialchars($_GET[url], ENT_QUOTES);
?
替换掉url里面的单引号和双引号，看起来是过滤的不错的，但是如果这个url没有出现单引号或双引号呢？或者双引号和单引号以另外的情况出现呢（二次编码）？
关于二次编码：
scriptalert(document.cookie)/script
如UTF-7编码后的
+ADw-SCRIPT+AD4-alert(document.cookie)+ADw-/SCRIPT+AD4-
最终为：
%2bADw-SCRIPT%2bAD4-alert(document.cookie)%2bADw-%2fSCRIPT%2bAD4-
可以考虑用于对付那些没有设置字符集，并且过滤了 的情况。
web攻击有哪些？怎么防护？
1、DoS和DDoS攻击（DoS(Denial of Service)，即拒绝服务，造成远程服务器拒绝服务的行为被称为DoS攻击。其目的是使计算机或网络无法提供正常的服务。最常见的DoS攻击有计算机网络带宽攻击和连通性攻击）
防范：(1) 反欺骗：对数据包的地址及端口的正确性进行验证，同时进行反向探测。(2) 协议栈行为模式分析：每个数据包类型需要符合RFC规定，这就好像每个数据包都要有完整规范的着装，只要不符合规范，就自动识别并将其过滤掉。(3) 特定应用防护：非法流量总是有一些特定特征的，这就好比即便你混进了顾客群中，但你的行为还是会暴露出你的动机，比如老重复问店员同一个问题，老做同样的动作，这样你仍然还是会被发现的。(4) 带宽控制：真实的访问数据过大时，可以限制其最大输出的流量，以减少下游网络系统的压力。
2、CSRF(Cross Site Request Forgery)，即跨站请求伪造，是一种常见的Web攻击，但很多开发者对它很陌生。CSRF也是Web安全中最容易被忽略的一种攻击。
防范：(1) 验证码。应用程序和用户进行交互过程中，特别是账户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在通常情况下，验证码够很好地遏制CSRF攻击。但增加验证码降低了用户的体验，网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段，在关键业务点设置验证码。(2) Referer Check。HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，一般会带上Referer信息告诉服务器是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律，如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面，来判断是不是CSRF攻击。但在某些情况下如从https跳转到http，浏览器处于安全考虑，不会发送referer，服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。出于以上原因，无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。(3) Anti CSRF Token。目前比较完善的解决方案是加入Anti-CSRF-Token，即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token和cookie当中的token值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。这种方法相比Referer检查要安全很多，token可以在用户登陆后产生并放于session或cookie中，然后在每次请求时服务器把token从session或cookie中拿出，与本次请求中的token 进行比对。由于token的存在，攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时，当某个页面消耗掉token后，其他页面的表单保存的还是被消耗掉的那个token，其他页面的表单提交时会出现token错误。
3、XSS(Cross Site Scripting)，跨站脚本攻击。为和层叠样式表(Cascading Style Sheets，CSS)区分开，跨站脚本在安全领域叫做“XSS”。
防范：(1) 输入过滤。永远不要相信用户的输入，对用户输入的数据做一定的过滤。如输入的数据是否符合预期的格式，比如日期格式，Email格式，电话号码格式等等。这样可以初步对XSS漏洞进行防御。上面的措施只在web端做了限制，攻击者通抓包工具如Fiddler还是可以绕过前端输入的限制，修改请求注入攻击脚本。因此，后台服务器需要在接收到用户输入的数据后，对特殊危险字符进行过滤或者转义处理，然后再存储到数据库中。(2) 输出编码。服务器端输出到浏览器的数据，可以使用系统的安全函数来进行编码或转义来防范XSS攻击。在PHP中，有htmlentities()和htmlspecialchars()两个函数可以满足安全要求。相应的JavaScript的编码方式可以使用JavascriptEncode。(3) 安全编码。开发需尽量避免Web客户端文档重写、重定向或其他敏感操作，同时要避免使用客户端数据，这些操作需尽量在服务器端使用动态页面来实现。(4) HttpOnly Cookie。预防XSS攻击窃取用户cookie最有效的防御手段。Web应用程序在设置cookie时，将其属性设为HttpOnly，就可以避免该网页的cookie被客户端恶意JavaScript窃取，保护用户cookie信息。(5)WAF(Web Application Firewall)，Web应用防火墙，主要的功能是防范诸如网页木马、XSS以及CSRF等常见的Web漏洞攻击。由第三方公司开发，在企业环境中深受欢迎。
4、SQL注入(SQL Injection)，应用程序在向后台数据库传递SQL(Structured Query Language，结构化查询语言)时，攻击者将SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
防范：(1) 防止系统敏感信息泄露。设置php.ini选项display_errors=off，防止php脚本出错之后，在web页面输出敏感信息错误，让攻击者有机可乘。(2) 数据转义。设置php.ini选项magic_quotes_gpc=on，它会将提交的变量中所有的’(单引号)，”(双引号)，\(反斜杠)，空白字符等都在前面自动加上\。或者采用mysql_real_escape()函数或addslashes()函数进行输入参数的转义。(3) 增加黑名单或者白名单验证。白名单验证一般指，检查用户输入是否是符合预期的类型、长度、数值范围或者其他格式标准。黑名单验证是指，若在用户输入中，包含明显的恶意内容则拒绝该条用户请求。在使用白名单验证时，一般会配合黑名单验证。
5、上传漏洞在DVBBS6.0时代被黑客们利用的最为猖獗，利用上传漏洞可以直接得到WEBSHELL，危害等级超级高，现在的入侵中上传漏洞也是常见的漏洞。该漏洞允许用户上传任意文件可能会让攻击者注入危险内容或恶意代码，并在服务器上运行。
防范： (1)检查服务器是否判断了上传文件类型及后缀。 (2) 定义上传文件类型白名单，即只允许白名单里面类型的文件上传。 (3) 文件上传目录禁止执行脚本解析，避免攻击者进行二次攻击。 Info漏洞 Info漏洞就是CGI把输入的参数原样输出到页面，攻击者通过修改输入参数而达到欺骗用户的目的。
xss包搭配localstorage可以预防xss攻击么
不可以。存放在LocalStorage中如果受到XSS攻击会产生巨大的安全隐患，如果一个站点容易受到XSS攻击，LocalStorage是不安全的也许对使用本地存储的最大反对是与之相关的安全漏洞。
SpringBoot 防止SQL注入、XSS攻击、CSRF/CROS恶意访问
一、SQL 注入问题
SQL 注入即是指 web 应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在 web 应用程序中事先定义好的查询语句的结尾上添加额外的 SQL 语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。
简单来说，就是将大部分 SQL 语句当参数传入系统中，从而获取系统中的数据。下面简单举例说明
系统中有这样一条信息 SQL 语句执行，分页查询所有用户，每页查询 20 条，并且根据指定字段进行排序，也就是说排序字段也是参数传递过来的
SQL 注入问题分析：
这样很简单的一句话 SQL，就可以把系统搞炸掉，这种方式可以实现删库跑路
以上语句会把整个 test 数据库所有内容都删掉
尽量用预编译机制，少用字符串拼接的方式传参，它是 sql 注入问题的根源。
有些特殊字符，比如：%作为 like 语句中的参数时，要对其进行转义处理。
需要对所有的异常情况进行捕获，切记接口直接返回异常信息，因为有些异常信息中包含了 sql 信息，包括：库名，表名，字段名等。攻击者拿着这些信息，就能通过 sql 注入随心所欲地攻击你的数据库了。目前比较主流的做法是，有个专门的网关服务，它统一暴露对外接口。用户请求接口时先经过它，再由它将请求转发给业务服务。这样做的好处是：能统一封装返回数据的返回体，并且如果出现异常，能返回统一的异常信息，隐藏敏感信息。此外还能做限流和权限控制。
使用 sqlMap 等待代码检测工具，它能检测 sql 注入漏洞。
需要对数据库 sql 的执行情况进行监控，有异常情况，及时邮件或短信提醒。
对生产环境的数据库建立单独的账号，只分配 DML 相关权限，且不能访问系统表。切勿在程序中直接使用管理员账号。
建立代码 review 机制，能找出部分隐藏的问题，提升代码质量。
对于不能使用预编译传参时，要么开启 druid 的 filter 防火墙，要么自己写代码逻辑过滤掉所有可能的注入关键字。
XSS 攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是 JavaScript，但实际上也可以包括 Java、 VBScript、ActiveX、 Flash 或者甚至是普通的 HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和 cookie 等各种内容。
通常情况下，被用来盗用 Cookie、破坏页面结构、重定向到其他网站等
对用户输入的表单信息进行检测过滤
CSRF - Cross-Site Request Forgery - 跨站请求伪造:
攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在未授权的情况下执行在权限保护之下的操作，CORS - Cross Origin Resourse-Sharing - 跨站资源共享，恶意访问内网敏感资源。
有效的解决办法是通过多种条件屏蔽掉非法的请求，例如 HTTP 头、参数等：
防止大规模的恶意请求，niginx 反向代理可以配置请求频率，对 ip 做限制。nginx 可以很方便地做访问控制，特别是一些偶发性的大量恶意请求，需要屏蔽处理。
屏蔽 ip 地址
屏蔽 user-agent
屏蔽代理 ip
有两种情形会需要屏蔽代理 ip：一是代理 ip 访问，二是负载均衡（real-ip 请求负载均衡服务器，再代理给后端 server）
创建 XssAndSqlHttpServletRequestWrapper 包装器，这是实现 XSS 过滤的关键，在其内重写了 getParameter，getParameterValues，getHeader 等方法，对 http 请求内的参数进行了过滤
XSS攻击原理是什么？
什么是XSS攻击XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。而本文主要讲的是利用XSS得到目标服务器的shell。技术虽然是老技术，但是其思路希望对大家有帮助。 [编辑本段]如何寻找XSS漏洞就个人而言，我把XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。另一类则是来来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。
asp.net如何防止xss(脚本注入啊)
scriptalert('abc')/script 替换成scriptalert('abc')/script这样的话显示出来也是scriptalert('abc')/script 但是意义却不再是脚本而是字符串了。可以通过替换把这两个符号替换掉即可。