关于安全:SAFEBASE渗透攻防与常见安全基础问题集合

SQL 注入，就是利用现有 Web 应用程序，构建非凡的参数输出，将（歹意的）SQL 语句注入到后盾数据库引擎，最终达到坑骗服务器执行歹意 SQL 语句的目标。

分类：

依据注入点地位的不同，可分为列注入、表注入、order 注入、limit 注入、group by 注入等。

依据注入模式的不同，可分为数字型注入、字符型注入、搜寻型注入。

依据申请形式的不同，可分为 GET 型注入、POST 型注入、HEADER 型注入。

危害：脱库，导致敏感数据透露；getshell, 获取服务器权限。
进攻：对用户输出的参数作好预编译解决，不能预编译的，可采取平安过滤，类型判断，映射等形式进行解决。

纯盲注
order 注入
limit 注入
宽字节注入
二次注入
简略注入绕过
注入拿 shell

罕用函数

substring() substr() mid()
ascii() if() case when() 
sleep()
updatexml() extractvalue() floor() 
concat() concat_ws()
user() database()
procedure analyse()

SQL 注入自动化利用工具

sqlmap 下载地址：https://github.com/sqlmapproject/sqlmap 应用教程：https://www.tr0y.wang/2018/03/21/sqlmap-guide/

https://octobug.gitbooks.io/sqlmap-wiki-zhcn/content/
https://github.com/wizardforcel/mst-sec-lecture-notes/blob/master/%E6%BC%8F%E6%B4%9E%E7%AF%87%20SQL%E6%B3%A8%E5%85%A5.md
https://b1ngz.github.io/java-sql-injection-note/
http://sqlwiki.radare.cn/

asctime()函数是将一个 tuple 或者是 struct_time 示意的工夫模式转换成相似于 Sun Jun 20 23:21:05 1993 的模式，对 time.struct_time(tm_year=2015, tm_mon=11, tm_mday=7, tm_hour=20, tm_min=58, tm_sec=57, tm_wday=5, tm_yday=311, tm_isdst=0)中每一个键值设置 invalid_time 可造成溢出谬误。

在 Python 2.6.x 中报错为

OverflowError: long int too large to convert to int

在 Python 2.7.x 中报错为

OverflowError: Python int too large to convert to C long
OverflowError: signed integer is greater than maximum

因而开发过程中须要思考工夫日期的格局，避免溢出导致信息泄露!

time.gmtime()为将秒数转化为 struct_time 格局，它会基于 time_t 平台进行测验，如上代码中将秒数扩充进行测试时会产生报错ValueError: timestamp out of range for platform time_t。如果数值在 -2^63 到 -2^56 之间或者 2^55 到 2^62 之间又会引发另一种报错ValueError: (84, 'Value too large to be stored in data type')。

os.utime(path, times)是设置对应文件的 access 和 modified 工夫，工夫以 (atime, mtime) 元组的模式传入，代码中将 modified time 设置过大也会产生报错。

在 Python 2.6.x 中报错为

OverflowError: long int too large to convert to int

在 Python 2.7.x, Python 3.1 中报错为

OverflowError: Python int too large to convert to C long

如果咱们将其中的 modified time 设置为 2^55，ls 后会有：

$ ls -la temp.bin
-rw-r--r-- 1 user01 user01 5 13 Jun 1141709097 temp.bin $ stat temp.bin
A:"Oct 10 16:31:45 2015"
M:"Jun 13 01:26:08 1141709097"
C:”Oct 10 16:31:42 2015"

在某些操作系统上如果咱们将值设为 2^56，将会有以下输入（也有造成零碎解体和数据失落的危险）：

$ ls -la temp.bin

Segmentation fault: 11

$ stat temp.bin
A:"Oct 10 16:32:50 2015"
M:"Dec 31 19:00:00 1969"
C:"Oct 10 16:32:50 2015

Modules 通常没有对有效输出进行查看或者测试。例如，对于 64 位的操作系统，最大数能够达到 2^63-1，然而在不同的状况下应用数值会造成不同的谬误，任何超出无效边界的数字都会造成溢出，所以要对无效的数据进行测验。

问题在于：ctypes 对内存大小没有限度, 也没有对溢出进行查看.
所以，在 32 位和 64 位操作系统上都能够造成溢出，解决方案就是也要对数据的有效性和溢出进行查看。

xrange 应用 Plain Integer Objects 而无奈承受任意长度的对象。解决办法就是应用 Python 的 long integer object，这样就能够应用任意长度的数字了，限度条件则变为操作系统内存的大小了。

因为 len()函数没有对对象的长度进行查看，也没有应用 python int objects（应用了就会没有限度），当对象可能蕴含一个“.length”属性的时候，就有可能造成溢出谬误。解决办法同样也是应用 python int objects。

将 Decimal 实例和浮点值进行比拟，在不同 Python 版本中如果无奈比拟则用 except 捕捉异样，输入状况为：

在 Python 2.6.5, 2.7.4, 2.7.10 中输入 ERROR: FLOAT seems comparable with DECIMAL (WRONG)

在 Python 3.1.2 中输入 OK: FLOAT is NOT comparable with DECIMAL (CORRECT)

将字符串和浮点值进行比拟，在不同 Python 版本中如果无奈比拟则用 except 捕捉异样，输入状况为：

在 Python 2.6.5, 2.7.4, 2.7.10 中输入 ERROR: FLOAT seems comparable with STRING (WRONG)

在 Python 3.1.2 中输入 OK: FLOAT is NOT comparable with STRING (CORRECT)

在应用同一种类型的对象进行比拟之后，Python 内置的比拟函数就不会进行测验。但在以上两个代码例子当中 Python 并不知道该如何把 STRING 和 FLOAT 进行比拟，就会间接返回一个 FALSE 而不是产生一个 Error。同样的问题也产生于在将 DECIMAL 和 FLOATS 时。解决方案就是应用强类型（strong type）检测和数据验证。

应用__import__导入 os,

再联合 eval()就能够执行命令了。只有用户加载了解释器就能够没有限度地执行任何命令。

以上的代码将 x41xF5x42x43xF4 以二进制的模式写入文件，再别离用 codecs 和 io 模块进行读取，编码模式为 utf-8，对 xF5 和 xF4 不能编码的设置 errors=’replace’，编码成为 \ufffd，最初后果如下：

Correct-String —> “u’A\ufffdBC\ufffd'”

CODECS-String —> “u’A\ufffdBC'” (WRONG)

IO-String —> “u’A\ufffdBC\ufffd'” (OK)

当 codecs 在读取 x41xF5x42x43xF4 这个字符串的时候，它冀望接管到蕴含 4 个字节的序列，而且因为在读入 xF4 的时候它还会再期待其余 3 个字节，而没有进行编码，后果就是失去的字符串有一段被删除了。更好且平安的办法就是应用 os 模块，读取整个数据流，而后进行解码解决。解决方案就是应用 io 模块或者对字符串进行辨认和确认来检测畸形字符。

在不同的平台上，环境变量名的名称和语法都是基于不同的规定。但 Python 并不恪守同样的逻辑，它尽量应用一种广泛的接口来兼容大多数的操作系统。这种器重兼容性大于平安的抉择，使得用于环境变量的逻辑存在缺点。
解决方案是对基础设施和操作系统进行检测，检测和环境变量相干的键值对，阻止一些对操作系统为空或者有效键值对的应用。

结构歹意序列化字符串，以二进制的模式写入文件中，应用 pickle.load()函数加载进行反序列化，还原出原始 python 对象，从而应用 os 的 system()函数来执行命令 ”ls -la /”。因为 pickle 这样不平安的设计，就能够借此来执行命令了。

依据应用的 Python 版本不同，pickle 或 cPickle 要么保留截断的数据而没有谬误要么就会保留限度为 32bit 的局部。而且依据 Python 在操作系统上装置时编译的状况，它会返回在申请随机数据大小上的谬误，或者是报告有效参数的 OS 谬误

解决方案就是执行弱小的数据检测来确保不会执行危险行为，还有即便在 64 位的操作系统上也要限度数据到 32 位大小。

在 Python2 中没有蕴含原子操作，外围库是在应用缓存进行读写。所以应该尽量去应用 io 模块。

结构了一个 HTTP 服务端，如果一个客户端连贯进来，再去敞开服务端，Python 将不会开释资源，操作系统也不会开释 socket，引发报错为 socket.error: [Errno 48] Address already in use!
解决方案就是每一个协定库都应该由这样的库封装：为每一个 OS 和协定都适当地建设和撤销通信，并开释资源

以上代码当中，首先开启一个虚构的服务端，应用客户端去连贯服务端，而后服务端开始发送空字符，客户端持续性接管空字符，最初到客户端内存填满，零碎解体，解决方案就是如果无法控制检查数据的类型和大小，就应用 Python > 2.7.9’ 或者 ’Python > 3.3’ 的版本

urllib2 并没有适合的逻辑来解决数据流而且每次都会失败，将上次代码运行三次都会失去谬误的文件大小的输入

ast
bastion
commands
cookie
cpickle/pickle
eval
marshal
mktemp
multiprocessing
os.exec
os.popen
os.spawn
os.system
parser
pipes
pty
rexec
shelve
subprocess
tarfile
urllib2
urlparse
yaml
zipfile

API 平安设计指南：http://blog.nsfocus.net/rest-api-design-safety/

sql 注入产生的起因是开发人员在进行数据库操作是，未针对用户的输出进行过滤和预编译解决，从而导致攻击者能够管制数据库查询语言而进行非法操作，如下所示：

var query = "SELECT name FROM Users WHERE login='" + req.body.login + "'"; db.sequelize.query(query,{ model: db.User}).then(user => { if(user.length){

修复计划，针对参数进行预编译解决

if (vh.vCode(req.body.login)){db.User.find({where:{'login':req.body.login}}).then(user => { if (user) {

命令注入产生的起因是开发人员在调用系统命令是，采纳危险的系统命令执行函数，并且过于信赖系统命令传递的参数，导致攻击者能够通过管道命令拼接的形式去执行任意系统命令，如下所示：

const exec = require('child\_process').exec; ... exec('ping -c 2'+ req.body.address, function(err,stdout,stderr){console.log(err) output = stdout + stderr

修复计划，采纳平安的系统命令调用函数，并且针对用户输出进行严格的校验

const execFile = require('child\_process').execFile; ... if (vh.vIP(req.body.address)){execFile('ping', \['-c', '2', req.body.address\] , function(err,stdout,stderr){output = stdout + stderr

暴力破解攻打次要产生在登陆业务模块中，因为零碎针对用户登陆生效性不足校验，导致攻击者能够通过主动的形式破解零碎的口令，从而获取零碎敏感数据修复倡议：针对用户登陆接口减少避免暴力破解的形式，如生物辨认、并减少账号或者 IP 锁定机制

敏感信息泄露在应用 NodeJS 开发中个别存在于无认证拜访接口、日志记录的业务场景外面，如下所示：

db.User.findAll({}).then(users => { res.status(200).json({success: true, users: users})

修复倡议：针对用户敏感数据进行脱敏解决，或者禁止接口返回记录用户敏感数据信息

db.User.findAll({attributes: \[ 'id' ,'name', 'email'\]},).then(users => { res.status(200).json({success: true, users: users})

xml 实体注入次要存在于应用 xml 实体解析的业务性能接口时，未对实体解析的内容进行过滤和校验，导致攻击者能够在 xml 实体中主任歹意的命令，从而获取零碎的敏感数据或者权限，如下所示：

module.exports.bulkProducts = function(req, res) {if (req.files.products & req.files.products.mimetype=='text/xml'){var products = libxmljs.parseXmlString(req.files.products.data.toString('utf8'), {noent:true,noblanks:true})

修复计划，非业务必须倡议禁用 xml 实体解析性能

module.exports.bulkProducts = function(req, res) {if (req.files.products & req.files.products.mimetype=='text/xml'){var products = libxmljs.parseXmlString(req.files.products.data.toString('utf8'), {noent:false,noblanks:true})

xss 注入次要的产生的起因是因为开发人员针对用户输出过于信赖，导致用户能够任意写入 js 语言输入到页面上，从而导致 js 代码执行，获取用户敏感的 cookie 数据信息。

<td><%- output.products[i].id %></td>
<td><%- output.products[i].name %></td>
<td><%- output.products[i].code %></td>
<td><%- output.products[i].tags %></td>

修复计划：xss 修复计划的八字准则，输出过滤、输入编码

<td><%= output.products[i].id %></td>
<td><%= output.products[i].name %></td>
<td><%= output.products[i].code %></td>
<td><%= output.products[i].tags %></td>

在应用 NodeJS 开发的场景中，如果在序列化和发序列化操作的过程中，未对反序列话生成的对象进行校验，会导致近程命令执行如下所示：

module.exports.bulkProductsLegacy = function (req,res){// TODO: Deprecate this soon if(req.files.products){var products = serialize.unserialize(req.files.products.data.toString('utf8'))

修复计划：针对反序列化产生的对象进行严格的校验，避免歹意的代码生产

module.exports.bulkProductsLegacy = function (req,res){// TODO: Deprecate this soon if(req.files.products){var products = JSON.parse(req.files.products.data.toString('utf8'))

不平安的访问控制个别存在于利用接口的未受权拜访导致泄露零碎敏感信息，如 swagger-ui，spring-acutotar 等业务场景，在应用 Nodejs 开发的利用零碎中，同样须要留神应用平安的访问控制，避免信息泄露，如下所示

... router.get('/admin',authHandler.isAuthenticated,function(req,res){res.render('app/admin',{admin: (req.user.role=='admin')}) })

router.get('/admin/api/users',authHandler.isAuthenticated, appHandler.listUsersAPI) ...

修复计划：针对对外开发的接口减少强身份验证机制，避免未受权拜访导致的信息泄露

... var isAdmin = false; if(!isAdmin){var div = document.getElementById('admin-body'); div.style.display = "none"; }else{var div = document.getElementById('non-admin-body'); div.style.display = "none";  
} ...

软件过程中通常会应用开发第三方组件来晋升编码效率，缩小反复造轮子，然而随着不平安的第三方组件引入会对利用零碎带来新的平安威逼，因而在 NodeJS 开发过程中，应用的第三方组件须要进行严格的平安审核和扫描，避免引入存在平安危险的组件库如 mathjs

修复倡议: 1、应用平安的组件库替换 2、针对用户的输出进行合法性校验

在应用 NodejS 开发利用过程中，为了不便定位问题，存在生产环境中开启 debug 模式的业务场景，在该模式下，会存在信息泄露的平安危险，导致攻击者能够很轻易的获取零碎的敏感信息，如下所示：

... if(req.body.eqn){req.flash('result',mathjs.eval(req.body.eqn)) res.render('app/calc') ... 修复计划：生产环境禁止开启 debug 模式，同时针对利用零碎接口的报错信息对立解决 try{result = mathjs.eval(req.body.eqn) }catch (err){result = 'Invalid Equation'}

DVNA 是一个采纳纯 NodeJS 编写的 web 利用靶场，针对 owasp top10 类型的破绽都有相干的破绽测试验证，学员能够通过靶场的实际操作，真正意义上的了解和把握 NodeJS 平安开发标准；

1、https://github.com/appsecco/dvna 2、NodeJS 平安开发标准：参考附件 3、NodeJS 开发文档：http://nodejs.cn/api/

APP 开发时须要留神，用户的敏感信息个别准则是尽量加密保留在服务器上，特地是明码须要应用 Hash 加 salt 的办法，并且传输的时候须要应用 HTTPS 加密传输，业务所需，切实要保留在本地的敏感信息，须要加密保留在本地，另外保留在 Keychain 中的数据也须要加密；

加密算法须要应用平安的加密算法：平安的对称加密算法包含：AES128、AES192、AES256 以及国密 SM1；平安的非对称加密算法包含：RAS2048、ECC256、SM2（特地留神位数肯定要够，RSA 至多是 2048 位）；平安的 Hash 包含 SHA2（SHA224、SHA256 等）、SHA3、SM3。不平安的加密算法禁止应用包含：不平安的对称加密算法：DES、3DES；不平安 Hash 函数：MD5、SHA1。

上线的 APP 要敞开日志；对于金融类 APP 来说，最好自定义键盘；当在有敏感信息的页面进入后盾后，须要模糊化页面解决；对于企业外部应用的 APP，如果须要许禁止复制和粘贴利用内的数据到内部。
Keychain 的平安属性 kSecAttrAccessibleAlways、kSecAttrAccessibleAlwaysThisDeviceOnly 不倡议应用，倡议应用 kSecAttrAccessibleWhenUnlockedThisSDeviceOnly。

代码中禁止硬编码用户明码等敏感信息以及硬编码用户的密钥信息。

因为 UIWebView 默认开启 WebKitAllowFileAccessFromURLs 等，存在 File 逾越破绽，禁止应用 UIWebView, 举荐应用 WKWebView。

当应用 URL Scheme 唤起利用时，只容许白名单内的 APP 通过 URL Scheme 唤起利用。

iOS APP 上线前能够进行加固解决，能够应用商业工具，也能够本人进行解决，包含对字符串混同、类名办法混同、程序代码逻辑混同和退出平安的 SDK 用于越狱检测、调试检测、注入检测。

应用的 Xcode 和第三方库，最好到官网下载，应用前须要查问是否有 cve 破绽。

参考文献

《iOS Hacking Guide》
《黑客攻防技术宝典：iOS 实战篇》
http://damnvulnerableiosapp.com

iOS 重签名
iOS 逆向之 framework 注入

SSRF(Server-Side Request Forgery), 服务器申请伪造，是指利用能够发动网络申请的内部利用和服务当作跳板来攻打外部其余利用和服务的一种攻击方式。
该破绽为服务器发动网络申请从近程获取资源，申请的指标地址和协定用户可控并且服务端并未做钻研校验导致，常见于社交分享、图片下载等性能。
常见的可能触发该破绽的函数包含 PHP 中的 file_get_content、fsockopen、curl_exec 等。
通常能够通过 SSRF 探测内网利用，读取文件，甚至是作为跳板攻打内网利用，如应用 gopher 协定利用内网 redis 写入文件 getshell。
个别通过校验参数 url 等形式进行进攻，然而不充沛的校验能够通过奇妙地结构 url 等形式绕过。

类型	存储区域	插入点
反射型	URL	HTML
存储型	后端数据库	HTML
DOM 型	数据库 / 前端存储 /URL	前端 Javascript

常见输出点
- 输入到 HTML 标签中
- 输入到 HTML 标签属性值中
- 生产 HTML 标签事件
- 输入到 DOM 中
- 其余

注意：1、内部元素 (svg, math) 标签中能进行 html 解码 2、RCDATA 元素标签 (textarea, title) 下不能创立新标签，不能执行脚本

对于编码解码
- HTML 实体编码：10 进制 /16 进制在 html 解析时能被解码应用实体名称：< > 实体编号（10 进制）：&#60; &#62; 实体编号（16 进制）：&#x3c; &#x3e;
- Javascript 编码：javascript8 进制编码，16 进制编码，Jsunicode 编码在 javascript 中能被解码应用 10 进制：\74\76 16 进制：\x3c\x3e
- Unicode：\u003c \u003e URL 编码：应用 javascript 伪协定的标签属性下，可应用 base64 编码在 URL 中能被解码应用【协定://】这些不能编码
防护绕过的个别办法：详见 ppt
防护倡议：
- 利用模板引擎模板引擎个别自带本义，需尽量放弃最新，防止低版本破绽
- 防止内联事件尽量不要用 onLoad=“onload(‘{{data}}’)”onClick=“go(‘{{action}}’)”这种写法
- 防止拼接 HTML 应用成熟的渲染框架，并放弃新版本 + 后端过滤，如 vue，angular 等应用成熟的过滤器，并放弃新版本，如 ESAPI，Dompurify 等
- 减少攻打难度，升高攻打结果严格白名单、标准的 CSP、限度长度、http-only 等

所谓 CSRF 破绽，就是通过浏览器的 cookie 机制，通过诱骗用户点击蕴含歹意 Javascript 代码的 HTML 页面，在用户不知情的状况下，触发对要害接口的调用。

CSRF 破绽的利用前提是：

用户已登录网站
网站的要害 API 接口没有对 CSRF 做进攻
用户点击拜访了攻击者的网页

CSRF 破绽的利用形式是：

GET 申请：img 标签 src= 属性;
POST 申请：form 表单，配合 Javascript 代码主动提交表单

CSRF 破绽的检测形式是：

查看申请中是否蕴含随机 token 内容
批改 token，查看接口的返回后果
批改 HTTP 头中的 Referer 字段，查看接口的返回后果

CSRF 破绽的进攻伎俩有：

基于白名单，查看 Referer 的内容
增加 CSRF token（倡议）
图形 / 短信验证码

XML 指可扩大标记语言(Extensible Markup Language)，次要用来传输数据。XML 从 1995 年开始有其雏形，在 1998 年 2 月 10 日成为 W3C 的标准(XML1.0)。

DTD(Document Type Definition): 文档类型定义，用于定义 XML 文档的合法构建模块，应用一系列非法的元素来定义文档的构造，对 XML 文档元素进行束缚和验证。DTD 可被成行地申明于 XML 文档中，也可作为一个内部援用。

XXE 破绽正是借助 DTD 施行攻打。XXE 破绽的根本原因是对非平安的内部实体数据进行解析解决导致的平安问题。常见编程语言如 PHP、JAVA、Python、.NET 等使用不当均可能存在 XXE 破绽。2. XXE 破绽利用

不同编程语言可应用不同协定进行攻打。

近程文件读取
命令执行 (PHP expect)
内网端口扫描
攻打内网网站
dos 攻打
XXE 破绽的进攻
禁用内部实体

http://oxmlxxe.github.io/
https://github.com/JoyChou93/…
https://github.com/swisskyrep… Injection

防止间接应用不可信数据来拼接 SQL 语句

防止间接应用不可信数据来拼接 XML

防止间接应用不可信数据来记录日志

防止向 Runtimeexec() 办法传递不可信、未污染的数据

避免用户输出未通过验证间接输入到 html 界面

及时删除应用结束的临时文件

在多用户零碎中创立文件时指定适合的拜访许可

限定上传文件的格局和大小

敏感数据的加密和签名

禁止序列化未加密的敏感数据

避免序列化和反序列化被利用来绕过平安治理

将所有平安敏感代码都放在一个 jar 包中，签名再加密

生产代码防止蕴含任何调试入口点

禁止在日志中保留敏感数据

平安加密算法

增加盐值（salt）

禁止硬编码敏感信息

应用强随机数

fastjson
2017 年 3 月 15 日，FastJson 官网公布平安布告示意 fastjson 在 1.2.24 及之前版本存在近程代码执行高危安全漏洞。破绽产生的起因是因为 fastjson 反序列化 Json 字符串为 Java 对象时 autoType 没有做正确的检测解决，反对应用 autoType 来实例化任意类。

Fred Long, Dhruv Mohindra, Robert C. Seacord, Dean F. Sutherland, David Svoboda. The CERT Oracle Secure Coding Standard for Java. Addison-Wesley Professional, 2011
Secure Coding Guidelines for the Java Programming Language. http://www.oracle.com/technet…
CWE&SANS TOP 25, http://www.sans.org/top25-sof…
OWASP Guide Project, https://www.owasp.org/index.p…

js 查看
上传非凡后缀
.htaccess 绕过
Windows 个性（点号、空格、::$DATA）
后缀大小写绕过
双后缀绕过
解析破绽
MIME 绕过
截断绕过
文件头查看
Getimagesize 绕过
exif_imagetype 绕过
图片二次渲染绕过
条件竞争、数组绕过
apache 解析破绽
IIS 解析破绽
PUt 办法
绕过 waf 等等

Xposed__Hook 根底入门教程

https://repo.xposed.info/module/mobi.acpm.sslunpinning

Android 整体加固 次要是将 apk 中的 dex 进行加密保留，同时将原 App 的入口改成壳程序；由壳程序对加密 dex 的解密，并且实现自定义的 DexClassLoader 对解密后 dex 的加载，和运行环境的调整批改，之后进入原 dex 的代码流程；因为在 dex 的加载过程中会调用到 dexopt 进行 dex 的优化，从而对 dvmDexFileOpenPartial、dexFileParse 等进行下断点即可 dump 出解密后的 dex，实现脱壳；
IDA 调试 Android 办法及简略的脱壳实现

关于安全:SAFEBASE渗透攻防与常见安全基础问题集合

SQL 注入

备注

参考资料

python 平安开发

工夫函数平安应用

astime

gmtime

Utime

计数函数平安

ctypes

xrange

len

Decimal

Type Comparsion

字符串函数平安

eval

codecs

os

文件函数平安

pickle

cPickle

File Open

协定函数平安

httplib

poplib

urllib

不平安的库

nodejs

1、sql 注入

2、命令注入

3、暴力破解

4、敏感信息泄露

5、XML 实体注入

6、xss 注入

7、不平安的反序列化

8、不平安的访问控制

9、应用不平安的第三方库

10、平安配置缺失

环境阐明

参考资料

iOS 平安开发

URL Scheme 和 WebView 平安

iOS 加固平安

Xcode 和第三方库平安

参考文献

web

ssrf

xss

csrf

xxe

XXE 破绽原理

XXE 破绽的危害

参考文献

JAVA

数据校验

I/ O 操作

序列化和反序列化

运行环境

其余

参考资料

文件上传

Android

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）