本文目录一览：
- 1、渗透测试应该怎么做呢？
- 2、怎么利用xss渗透测试？
- 3、跨站脚本攻击,如何利用工具和测试防范跨站点脚本攻击
- 4、如何防范XSS跨站脚本攻击测试篇
- 5、发现XSS漏洞的一般做法有哪些？
- 6、如何使用深度学习检测XSS
渗透测试应该怎么做呢？
01、信息收集
1、域名、IP、端口
域名信息查询：信息可用于后续渗透
IP信息查询：确认域名对应IP，确认IP是否真实，确认通信是否正常
端口信息查询：NMap扫描，确认开放端口
发现：一共开放两个端口，80为web访问端口，3389为windows远程登陆端口，嘿嘿嘿，试一下
发现：是Windows Server 2003系统，OK，到此为止。
2、指纹识别
其实就是网站的信息。比如通过可以访问的资源，如网站首页，查看源代码:
看看是否存在文件遍历的漏洞（如图片路径，再通过…/遍历文件）
是否使用了存在漏洞的框架（如果没有现成的就自己挖）
02、漏洞扫描
1、主机扫描
Nessus
经典主机漏扫工具，看看有没有CVE漏洞：
2、Web扫描
AWVS（Acunetix | Website Security Scanner）扫描器
PS：扫描器可能会对网站构成伤害，小心谨慎使用。
03、渗透测试
1、弱口令漏洞
漏洞描述
目标网站管理入口（或数据库等组件的外部连接）使用了容易被猜测的简单字符口令、或者是默认系统账号口令。
渗透测试
① 如果不存在验证码，则直接使用相对应的弱口令字典使用burpsuite 进行爆破
② 如果存在验证码，则看验证码是否存在绕过、以及看验证码是否容易识别
风险评级：高风险
安全建议
① 默认口令以及修改口令都应保证复杂度，比如：大小写字母与数字或特殊字符的组合，口令长度不小于8位等
② 定期检查和更换网站管理口令
2、文件下载（目录浏览）漏洞
漏洞描述
一些网站由于业务需求，可能提供文件查看或下载的功能，如果对用户查看或下载的文件不做限制，则恶意用户就能够查看或下载任意的文件，可以是源代码文件、敏感文件等。
渗透测试
① 查找可能存在文件包含的漏洞点，比如js，css等页面代码路径
② 看看有没有文件上传访问的功能
③ 采用…/来测试能否夸目录访问文件
风险评级：高风险
安全建议
① 采用白名单机制限制服务器目录的访问，以及可以访问的文件类型(小心被绕过)
② 过滤【./】等特殊字符
③ 采用文件流的访问返回上传文件（如用户头像），不要通过真实的网站路径。
示例：tomcat，默认关闭路径浏览的功能：
param-namelistings/param-name
param-valuefalse/param-value
3、任意文件上传漏洞
漏洞描述
目标网站允许用户向网站直接上传文件，但未对所上传文件的类型和内容进行严格的过滤。
渗透测试
① 收集网站信息，判断使用的语言（PHP，ASP，JSP）
② 过滤规则绕过方法：文件上传绕过技巧
风险评级：高风险
安全建议
① 对上传文件做有效文件类型判断，采用白名单控制的方法，开放只允许上传的文件型式；
② 文件类型判断，应对上传文件的后缀、文件头、图片类的预览图等做检测来判断文件类型，同时注意重命名（Md5加密）上传文件的文件名避免攻击者利用WEB服务的缺陷构造畸形文件名实现攻击目的；
③ 禁止上传目录有执行权限；
④ 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件。
4、命令注入漏洞
漏洞描述
目标网站未对用户输入的字符进行特殊字符过滤或合法性校验，允许用户输入特殊语句，导致各种调用系统命令的web应用，会被攻击者通过命令拼接、绕过黑名单等方式，在服务端运行恶意的系统命令。
渗透测试
风险评级：高风险
安全建议
① 拒绝使用拼接语句的方式进行参数传递；
② 尽量使用白名单的方式（首选方式）；
③ 过滤危险方法、特殊字符，如：【|】【】【；】【’】【"】等
5、SQL注入漏洞
漏洞描述
目标网站未对用户输入的字符进行特殊字符过滤或合法性校验，允许用户输入特殊语句查询后台数据库相关信息
渗透测试
① 手动测试：判断是否存在SQL注入，判断是字符型还是数字型，是否需要盲注
② 工具测试：使用sqlmap等工具进行辅助测试
风险评级：高风险
安全建议
① 防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔，如Java的预处理，PHP的PDO
② 拒绝使用拼接SQL的方式
6、跨站脚本漏洞
漏洞描述
当应用程序的网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。
三种XSS漏洞：
① 存储型：用户输入的信息被持久化，并能够在页面显示的功能，都可能存在存储型XSS，例如用户留言、个人信息修改等。
② 反射型：URL参数需要在页面显示的功能都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能。
③ DOM型：涉及DOM对象的页面程序，包括：document.URL、document.location、document.referrer、window.location等
渗透测试
存储型，反射型，DOM型
风险评级：高风险
安全建议
① 不信任用户提交的任何内容，对用户输入的内容，在后台都需要进行长度检查，并且对【】【】【"】【’】【】等字符做过滤
② 任何内容返回到页面显示之前都必须加以html编码，即将【】【】【"】【’】【】进行转义。
7、跨站请求伪造漏洞
漏洞描述
CSRF，全称为Cross-Site Request Forgery，跨站请求伪造，是一种网络攻击方式，它可以在用户毫不知情的情况下，以用户的名义伪造请求发送给被攻击站点，从而在未授权的情况下进行权限保护内的操作，如修改密码，转账等。
渗透测试
风险评级：中风险（如果相关业务极其重要，则为高风险）
安全建议
① 使用一次性令牌：用户登录后产生随机token并赋值给页面中的某个Hidden标签，提交表单时候，同时提交这个Hidden标签并验证，验证后重新产生新的token，并赋值给hidden标签；
② 适当场景添加验证码输入：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串；
③ 请求头Referer效验，url请求是否前部匹配Http(s)😕/ServerHost
④ 关键信息输入确认提交信息的用户身份是否合法，比如修改密码一定要提供原密码输入
⑤ 用户自身可以通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie；
8、内部后台地址暴露
漏洞描述
一些仅被内部访问的地址，对外部暴露了，如：管理员登陆页面；系统监控页面；API接口描述页面等，这些会导致信息泄露，后台登陆等地址还可能被爆破。
渗透测试
① 通过常用的地址进行探测，如login.html，manager.html，api.html等；
② 可以借用burpsuite和常规页面地址字典，进行扫描探测
风险评级：中风险
安全建议
① 禁止外网访问后台地址
② 使用非常规路径（如对md5加密）
9、信息泄露漏洞
漏洞描述
① 备份信息泄露：目标网站未及时删除编辑器或者人员在编辑文件时，产生的临时文件，或者相关备份信息未及时删除导致信息泄露。
② 测试页面信息泄露：测试界面未及时删除，导致测试界面暴露，被他人访问。
③ 源码信息泄露：目标网站文件访问控制设置不当，WEB服务器开启源码下载功能，允许用户访问网站源码。
④ 错误信息泄露：目标网站WEB程序和服务器未屏蔽错误信息回显，页面含有CGI处理错误的代码级别的详细信息，例如SQL语句执行错误原因，PHP的错误行数等。
⑤ 接口信息泄露：目标网站接口访问控制不严，导致网站内部敏感信息泄露。
渗透测试
① 备份信息泄露、测试页面信息泄露、源码信息泄露，测试方法：使用字典，爆破相关目录，看是否存在相关敏感文件
② 错误信息泄露，测试方法：发送畸形的数据报文、非正常的报文进行探测，看是否对错误参数处理妥当。
③ 接口信息泄露漏洞，测试方法：使用爬虫或者扫描器爬取获取接口相关信息，看目标网站对接口权限是否合理
风险评级：一般为中风险，如果源码大量泄漏或大量客户敏感信息泄露。
安全建议
① 备份信息泄露漏洞：删除相关备份信息，做好权限控制
② 测试页面信息泄露漏洞：删除相关测试界面，做好权限控制
③ 源码信息泄露漏洞：做好权限控制
④ 错误信息泄露漏洞：将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因
⑤ 接口信息泄露漏洞：对接口访问权限严格控制
10、失效的身份认证
漏洞描述
通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌， 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
渗透测试
① 在登陆前后观察，前端提交信息中，随机变化的数据，总有与当前已登陆用户进行绑定的会话唯一标识，常见如cookie
② 一般现在网站没有那种简单可破解的标识，但是如果是跨站认证，单点登录场景中，可能为了开发方便而简化了身份认证
风险评级：高风险
安全建议
① 使用强身份识别，不使用简单弱加密方式进行身份识别；
② 服务器端使用安全的会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储，在登出、闲置超时后使其失效。
11、失效的访问控制
漏洞描述
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。
渗透测试
① 登入后，通过burpsuite 抓取相关url 链接，获取到url 链接之后，在另一个浏览器打开相关链接，看能够通过另一个未登入的浏览器直接访问该功能点。
② 使用A用户登陆，然后在另一个浏览器使用B用户登陆，使用B访问A独有的功能，看能否访问。
风险评级：高风险
安全建议
① 除公有资源外，默认情况下拒绝访问非本人所有的私有资源；
② 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害；
③ 当用户注销后，服务器上的Cookie，JWT等令牌应失效；
④ 对每一个业务请求，都进行权限校验。
12、安全配置错误
漏洞描述
应用程序缺少适当的安全加固，或者云服务的权限配置错误。
① 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
② 默认帐户的密码仍然可用且没有更改。
③ 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
④ 对于更新的系统，禁用或不安全地配置最新的安全功能。
⑤ 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行相关安全配置。
渗透测试
先对应用指纹等进行信息搜集，然后针对搜集的信息，看相关应用默认配置是否有更改，是否有加固过；端口开放情况，是否开放了多余的端口；
风险评级：中风险
安全建议
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。在所有环境中按照标准的加固流程进行正确安全配置。
13、使用含有已知漏洞的组件
漏洞描述
使用了不再支持或者过时的组件。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。
渗透测试
① 根据前期信息搜集的信息，查看相关组件的版本，看是否使用了不在支持或者过时的组件。一般来说，信息搜集，可通过http返回头、相关错误信息、应用指纹、端口探测（Nmap）等手段搜集。
② Nmap等工具也可以用于获取操作系统版本信息
③ 通过CVE，CNVD等平台可以获取当前组件版本是否存在漏洞
风险评级：按照存在漏洞的组件的安全风险值判定当前风险。
安全建议
① 移除不使用的依赖、不需要的功能、组件、文件和文档；
② 仅从官方渠道安全的获取组件(尽量保证是最新版本)，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险；
③ 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。
详细学习可参考：
怎么利用xss渗透测试？
xss 全称跨站脚本攻击
本身不能对服务器产生影响，而是对浏览者或页面产生影响
分三种，反射型，存储型，DOM型
原理，对用户输入不过滤，导致输入信息转为JavaScript或html执行
简单用法盗取cookie，弹窗，页面跳转等，可配合csrf甚至是sql注入使用。
以上为纯理论，如何构造有效负荷请自行谷歌。
We are CLAY. No system is safe.
跨站脚本攻击,如何利用工具和测试防范跨站点脚本攻击
跨站点脚本（XSS）允许攻击者通过利用因特网服务器的漏洞来发送恶意代码到其他用户。攻击者利用跨站点脚本（XSS）攻击向那些看似可信任的链接中注入恶意代码。当用户点击了链接后，内嵌的程序将被提交并且会在用户的电脑上执行，这会使黑客获取访问权限并偷走敏感数据。攻击者使用XSS来攻击受害者机器上的漏洞并且传输恶意代码而不是攻击系统本身。 通过用户输入的数据返回错误消息的Web表格，攻击者可以修改控制Web页面的HTML代码。黑客能够在垃圾信息中的链接里插入代码或者使用欺诈邮件来诱使用户对其身份产生信任。 例如攻击者可以发送带有URL的邮件给受害人，这个URL指向一个Web站点并且提供浏览器脚本作为输入；或者在博客或诸如Facebook、Twitter这样的社交网站上发布恶意URL链接。当用户点击这个链接时，该恶意站点以及脚本将会在其浏览器上运行。浏览器不知道脚本是恶意的并将盲目地运行这个程序，这转而允许攻击者的浏览器脚本使用站点的功能来窃取cookie或者冒充合法的用户来完成交易。 一些通常的跨站点脚本预防的最佳实践包括在部署前测试应用代码，并且以快速、简明的方式修补缺陷和漏洞。Web应用开发人员应该过滤用户的输入来移除可能的恶意字符和浏览器脚本，并且植入用户输入过滤代码来移除恶意字符。通常管理员也可以配置浏览器只接受来自信任站点的脚本或者关闭浏览器的脚本功能，尽管这样做可能导致使用Web站点的功能受限。 随着时代的进步黑客们变得更加先进，使用收集的工具集来加快漏洞攻击进程。这意味着仅仅部署这些通常的XSS预防实践是不够的，保护和预防过程必须从底层开始并持续提升。预防过程必须在开发阶段开始，建立在一个牢靠、安全的开发生命周期方法论之上的Web应用在发布版本中不太可能暴露出漏洞。这样以来，不仅提升了安全性，也改善了可用性而且缩减了维护的总体费用，因为在现场环境中修补问题比在开发阶段会花费更多。 威胁建模在XSS预防中也是重要的一个方面，应该纳入到每个组织的安全开发生命周期当中。威胁建模评估和辨识在开发阶段中应用程序面临的所有的风险，来帮助Web开发人员更好地理解需要什么样的保护以及攻击一旦得逞将对组织产生怎样的影响。要辨识一个特定应用的威胁级别，考虑它的资产以及它访问的敏感信息量是十分重要的。这个威胁建模过程将确保在应用的设计和开发过程中战略性地融合了安全因素源码天空 ，并且增强了Web开发人员的安全意识。 对于大型项目的Web开发人员来说，源代码扫描工具和Web应用漏洞扫描器是提高效率和减少工作量的通常选择。
如何防范XSS跨站脚本攻击测试篇
不可信数据 不可信数据通常是来自HTTP请求的数据，以URL参数、表单字段、标头或者Cookie的形式。不过从安全角度来看，来自数据库、网络服务器和其他来源的数据往往也是不可信的，也就是说，这些数据可能没有完全通过验证。 应该始终对不可信数据保持警惕，将其视为包含攻击，这意味着在发送不可信数据之前，应该采取措施确定没有攻击再发送。由于应用程序之间的关联不断深化，下游直译程序执行的攻击可以迅速蔓延。 传统上来看，输入验证是处理不可信数据的最好办法，然而，输入验证法并不是注入式攻击的最佳解决方案。首先，输入验证通常是在获取数据时开始执行的，而此时并不知道目的地所在。这也意味着我们并不知道在目标直译程序中哪些字符是重要的。其次，可能更加重要的是，应用程序必须允许潜在危害的字符进入，例如，是不是仅仅因为SQL认为Mr. O'Malley名字包含特殊字符他就不能在数据库中注册呢? 虽然输入验证很重要，但这始终不是解决注入攻击的完整解决方案，最好将输入攻击作为纵深防御措施，而将escaping作为首要防线。 解码(又称为Output Encoding) “Escaping”解码技术主要用于确保字符作为数据处理，而不是作为与直译程序的解析器相关的字符。有很多不同类型的解码，有时候也被成为输出“解码”。有些技术定义特殊的“escape”字符，而其他技术则包含涉及若干字符的更复杂的语法。 不要将输出解码与Unicode字符编码的概念弄混淆了，后者涉及映射Unicode字符到位序列。这种级别的编码通常是自动解码，并不能缓解攻击。但是，如果没有正确理解服务器和浏览器间的目标字符集，有可能导致与非目标字符产生通信，从而招致跨站XSS脚本攻击。这也正是为所有通信指定Unicode字符编码(字符集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能够确保不可信数据不能被用来传递注入攻击。这样做并不会对解码数据造成影响，仍将正确呈现在浏览器中，解码只能阻止运行中发生的攻击。 注入攻击理论 注入攻击是这样一种攻击方式，它主要涉及破坏数据结构并通过使用特殊字符(直译程序正在使用的重要数据)转换为代码结构。XSS是一种注入攻击形式，浏览器作为直译程序，攻击被隐藏在HTML文件中。HTML一直都是代码和数据最差的mashup，因为HTML有很多可能的地方放置代码以及很多不同的有效编码。HTML是很复杂的，因为它不仅是层次结构的，而且还包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻击与XSS的关系，必须认真考虑HTML DOM的层次结构中的注入攻击。在HTML文件的某个位置(即开发者允许不可信数据列入DOM的位置)插入数据，主要有两种注入代码的方式： Injecting UP，上行注入 最常见的方式是关闭现有的context并开始一个新的代码context，例如，当你关闭HTML属性时使用"并开始新的 可以终止脚本块，即使该脚本块被注入脚本内方法调用内的引用字符，这是因为HTML解析器在JavaScript解析器之前运行。 Injecting DOWN，下行注入 另一种不太常见的执行XSS注入的方式就是，在不关闭当前context的情况下，引入一个subcontext。例如，将改为 ，并不需要躲开HTML属性context，相反只需要引入允许在src属性内写脚本的context即可。另一个例子就是CSS属性中的expression()功能，虽然你可能无法躲开引用CSS属性来进行上行注入，你可以采用x ss:expression(document.write(document.cookie))且无需离开现有context。 同样也有可能直接在现有context内进行注入，例如，可以采用不可信的输入并把它直接放入JavaScript context。这种方式比你想象的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。从本质上讲，如果这样做，你的应用程序只会成为攻击者将恶意代码植入浏览器的渠道。 本文介绍的规则旨在防止上行和下行XSS注入攻击。防止上行注入攻击，你必须避免那些允许你关闭现有context开始新context的字符;而防止攻击跳跃DOM层次级别，你必须避免所有可能关闭context的字符;下行注入攻击，你必须避免任何可以用来在现有context内引入新的sub-context的字符。 积极XSS防御模式 本文把HTML页面当作一个模板，模板上有很多插槽，开发者允许在这些插槽处放置不可信数据。在其他地方放置不可信数据是不允许的，这是“白名单”模式，否认所有不允许的事情。 根据浏览器解析HTML的方式的不同，每种不同类型的插槽都有不同的安全规则。当你在这些插槽处放置不可信数据时，必须采取某些措施以确保数据不会“逃离”相应插槽并闯入允许代码执行的context。从某种意义上说，这种方法将HTML文档当作参数化的数据库查询，数据被保存在具体文职并与escaping代码context相分离。 本文列出了最常见的插槽位置和安全放置数据的规则，基于各种不同的要求、已知的XSS载体和对流行浏览器的大量手动测试，我们保证本文提出的规则都是安全的。 定义好插槽位置，开发者们在放置任何数据前，都应该仔细分析以确保安全性。浏览器解析是非常棘手的，因为很多看起来无关紧要的字符可能起着重要作用。 为什么不能对所有不可信数据进行HTML实体编码? 可以对放入HTML文档正文的不可行数据进行HTML实体编码，如 标签内。也可以对进入属性的不可行数据进行实体编码，尤其是当属性中使用引用符号时。但是HTML实体编码并不总是有效，例如将不可信数据放入 directlyinascript insideanHTMLcomment inanattributename ...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/ inatagname 更重要的是，不要接受来自不可信任来源的JavaScript代码然后运行，例如，名为“callback”的参数就包含JavaScript代码段，没有解码能够解决。 No.2 – 在向HTML元素内容插入不可信数据前对HTML解码 这条规则适用于当你想把不可信数据直接插入HTML正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有HTML解码的方法且能够躲开下列字符。但是，这对于其他HTML context是远远不够的，你需要部署其他规则。 ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... 以及其他的HTML常用元素 使用HTML实体解码躲开下列字符以避免切换到任何执行内容，如脚本、样式或者事件处理程序。在这种规格中推荐使用十六进制实体，除了XML中5个重要字符(、、 、 "、 ')外，还加入了斜线符，以帮助结束HTML实体。 -- -- -- "--" '--''isnotrecommended /--/forwardslashisincludedasithelpsendanHTMLentity ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常见属性插入不可信数据前进行属性解码 这条规则是将不可信数据转化为典型属性值(如宽度、名称、值等)，这不能用于复杂属性(如href、src、style或者其他事件处理程序)。这是及其重要的规则，事件处理器属性(为HTML JavaScript Data Values)必须遵守该规则。 contentinsideUNquotedattribute content insidesinglequotedattribute 除了字母数字字符外，使用小于256的ASCII值HH格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space] % * + , - / ; = ^ 和 |。 ESAPI参考实施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信数据前，进行JavaScript解码 这条规则涉及在不同HTML元素上制定的JavaScript事件处理器。向这些事件处理器放置不可信数据的唯一安全位置就是“data value”。在这些小代码块放置不可信数据是相当危险的，因为很容易切换到执行环境，因此请小心使用。
发现XSS漏洞的一般做法有哪些？
关于发现时间，要具体到是检测什么目标了。找google的，和找腾讯的时间肯定不会一样。 至于“你们一般都是如何发现xss漏洞的？” 不同类型的XSS漏洞，可能不尽相同。
1.对于反射型XSS以及一些DOM XSS，一般建议是开发一些自动化的扫描工具进行扫描，并辅以手工分析。 另外一方面，搜索引擎也是快速寻找具有缺陷参数的好办法。
2.对于存储型XSS，
1) 对于单纯的输入-存储-输出点 的情况 （输入与输出点关系：一个地方输入，会有多个地方输出；不同地方输入，同一地方输出。绕了点 T T ...）。常规测试是正向直接输入内容，然后在输出点查看是否未过滤，当然你也可以先大胆假设输出点未过滤，反向寻找在何处进行输入，进而测试。
2）对于富文本，则需要对过滤器进行fuzz测试（人脑+自动化）了，正好乌云drops上有乌乌发了一篇：fuzzing XSS filter
3）第三类，就是一些WEB应用中所出现的DOM-存储型XSS，即输出点的无害内容，会经过js的一些dom操作变得危险（本质上和 第1点里的dom xss成因是一样的）。这一类的挖掘方法，个人觉得不太好总结。 其一，需要熟悉WEB应用的功能，其二，知道功能所对应的JS代码有哪些，其三，凭直觉猜测程序员会在哪些功能出现可能导致XSS的过滤遗忘或过滤错误（直觉是唬人的，其实就是你知道某些功能会需要某些代码实现，而这些代码常常容易出错），其四，需要有较好的代码阅读跟踪能力（JS一大坨。。还是蛮难读的.... 有些代码被混淆过，十分不易阅读，就会涉及到如何下断点进行调试的小技巧）。 我想，挖掘这一类的前提可能是需要有不错的前端开发经验，写多了，才会有足够的嗅觉。
其实吧，有时候专门去找漏洞会很累的，大什么怡情，小什么伤身，因此，我们还不如开心的敲敲代码，听听歌，静待生命中那些意外的收获。 这些收获经常来自身边的人发给你的一些事物。
最后，不论如何，基础很重要吧，内力不足，招式再多也没用，反之，草木竹石皆可为剑。
如何使用深度学习检测XSS
XSS跨站漏洞分为大致三种：储存型XSS，反射型XSS，和DOM型XSS，一般都是由于网站对用户输入的参数过滤不严格而调用浏览器的JS而产生的。XSS几乎每个网站都存在，google，百度，360等都存在，存在和危害范围广，危害安全性大。