黑客是指那些利用技术手段进入其没有权限进入的计算机系统的人。在虚拟的网络世界里活跃着这批特殊的人，他们有自视之高的才能和乐此不疲的创造欲。技术的进步给了他们充分表现自我的天地，同时也使计算机网络世界多了一份灾难，一般人们把他们成为黑客或骇客，前者更多是指具有反传统精神的程序员，后者更多则是利用工具攻击别人的攻击者，具有明显的贬义。无论黑客还是程序员员，后者更多则是利用工具攻击别人的攻击者，具有明显的贬义。无论黑客还是骇客，都是具备高超计算机知识又对他人造成一定影响的人。
分布式拒绝服务攻击可以使很多的计算机在同一时间遭受到攻击，使攻击的目标无法正常使用，分布式拒绝服务攻击已经出现了很多次，导致很多的大型网站都出现了无法进行操作的情况，这样不仅仅会影响用户的正常使用，同时造成的经济损失也是非常巨大的。分布式拒绝服务攻击方式在进行攻击的时候，可以对源IP地址进行伪造，这样就使得这种攻击在发生的时候隐蔽性是非常好的，同时要对攻击进行检测也是非常困难的，因此这种攻击方式也成为了非常难以防范的攻击。
ping命令的基本应用
一般情况下，用户可以通过使用一系列ping命令来查找问题出在什么地方，或检验网络运行的情况。
下面就给出一个典型的检测次序及对应的可能故障：
① ping 127.0.0.1
如果测试成功，表明网卡、TCP/IP协议的安装、IP地址、子网掩码的设置正常。如果测试不成功，就表示TCP/IP的安装或设置存在有问题。
② ping 本机IP地址
如果测试不成功，则表示本地配置或安装存在问题，应当对网络设备和通讯介质进行测试、检查并排除。
③ ping局域网内其他IP
如果测试成功，表明本地网络中的网卡和载体运行正确。但如果收到0个回送应答，那么表示子网掩码不正确或网卡配置错误或电缆系统有问题。
④ ping 网关IP
这个命令如果应答正确，表示局域网中的网关路由器正在运行并能够做出应答。
⑤ ping 远程IP
如果收到正确应答，表示成功的使用了缺省网关。对于拨号上网用户则表示能够成功的访问Internet（但不排除ISP的DNS会有问题）。
⑥ ping localhost
local host是系统的网络保留名，它是127.0.0.1的别名，每台计算机都应该能够将该名字转换成该地址。否则，则表示主机文件（/Windows/host）中存在问题。
⑦ ping www.yahoo.com（一个著名网站域名）
对此域名执行Ping命令，计算机必须先将域名转换成IP地址，通常是通过DNS服务器。如果这里出现故障，则表示本机DNS服务器的IP地址配置不正确，或它所访问的DNS服务器有故障
如果上面所列出的所有ping命令都能正常运行，那么计算机进行本地和远程通信基本上就没有问题了。但是，这些命令的成功并不表示你所有的网络配置都没有问题，例如，某些子网掩码错误就可能无法用这些方法检测到。
（3）ping命令的常用参数选项
ping IP -t：连续对IP地址执行ping命令，直到被用户以Ctrl C中断。
ping IP -l 2000：指定ping命令中的特定数据长度（此处为2000字节），而不是缺省的32字节。
ping IP -n 20：执行特定次数（此处是20）的ping命令。
古典密码编码方法归根结底主要有两种，即置换和代换。把明文中的字母重新排列，字母本身不变，但其位置改变了，这样编成的密码称为置换密码。最简单的置换密码是把明文中的字母顺序倒过来，然后截成固定长度的字母组作为密文。代换密码则是将明文中的字符替代成其他字符。
对称加密
对称加密与凯撒密码技术相同，发送者和接收者使用同一套规则来对数据进行加密和解密。如下图所示：
但对称加密技术不是完美的。
首先，发送者和接收者都是用同一个密钥（即同一套编译规则）。使用同一个密钥没问题，问题在于，如果我们想从从“窃听者”手里共享密钥，就会变得很难。
其次，我们使用对称加密技术来保证数据安全传输的同时，也必须将密钥共享给接收者。但是怎么把这个“密钥”安全地分享给接收者呢？这又是一个问题。
为了解决这个问题，于是有了“非对称加密”，这也是区块链里常用的密码学技术。
非对称加密
非对称加密比对称加密复杂一些，它们之间的主要区别是：对称加密使用共享密钥来解密数据，而非对称加密使用“密钥对”来解密数据。
密钥对包含两部分：一个公钥，一个私钥。
以发送邮件为例，假如我们使用邮箱给其他人发送邮件，首先需要有一个邮箱账号，并设置一个密码；接下来，输入收件人的邮箱账号；最后，收件人收到邮件并读取信息。
非对称加密的流程也和发送邮件一样。
每个用户都有一个公钥，和邮箱用户名一样，其他人可以看到或者获取这个“用户名”，但无法访问这个账户里的数据。私钥就和密码一样，只有账户拥有者知道。
发送数据时，我们需要使用私钥（即密码）和接收者公钥（即用户名）。接收者则使用他的私钥（密码）和发送者的公钥（用户名）来解密数据。整个流程如下图所示：
区块链不同于邮箱的地方在于：邮箱有一个中心化的数据库，如果我们丢失了密码，还可以通过数据库找回；区块链则是去中心化的，私钥一旦丢失就无法找回。
数字签名
发送邮件后，收件人看到我的邮箱账号就知道是我发送的。但有一个前提是，如果发送人没有密码，就无法发送信息。同样地，在非对称加密中，没有私钥，就没有人可以通过你的公钥发送消息。
当使用私钥发送数据时，它由我们的“数字签名”进行签名。数字签名（又称公钥数字签名）是只有信息的发送者才能产生的、别人无法伪造的一段数字串，这段数字串同时也是对信息发送者发送信息真实性的一个有效证明。
身份认证技术是在计算机网络中确认操作者身份的过程而产生的有效解决方法。 计算机网络世界中一切信息包括用户的身份信息都是用一组特定的数据来表示的，计算机只能识别用户的数字身份，所有对用户的授权也是针对用户数字身份的授权。
现有A用户和B用户之间想加密传输一些秘密文件，通过什么样的技术可以确保A和B传输数据的安全性？
采用对称秘钥对数据进行加密传输(对称加密算法计算效率高，速度快) AES、3DES、DES等
用户选择一种对称加密算法并与用户口令P(P的值假设为'user_passwd')对原始数据Data进行加密后生成加密后的数据P_DATA,再通过网络将P_DATA传递给B，B获取P_DATA后采用相同的用户口令P与相应的对称加密算法对数据进行解密，最终获得真正的数据DATA
| 产生的问题： A的加密口令P以及使用了哪种加密算法该如何告诉B，直接在公网传输有被窃取的风险。 | |
| 上述问题方案： 采用非对称秘钥算法将用户口令P加密(非对称加密算法计算效率低，速度慢，适用于加密数据量特别小的数据) 算法： RSA、ECC等 解决的问题：hash值解决<span style="color: #ff0000;">文件完整性 、公钥加密解决用口令P的私密性 工作原理： A用户使用B用户的公钥将用户口令P与加密算法的选择信息加密，连同P_DATA以及两者的hash值发送给B。B使用自身的私钥解密得到加密算法和对称加密算法的用户口令P，使用P解密得到原始数据Data。 | |
| 产生的问题： A如何获得B的公钥？如果A直接通过网络获取B的公钥则存在中间人劫持的风险，即中间有C冒充B将C的公钥发送给A，A又不对收到的公钥进行验证的话则C获取到加密后的数据后用自己的私钥即可将数据解密 | |
| 上述问题方案： CA机构介入 解决的问题： 身份</span>唯一性 背景： CA机构为可信任线下机构(类似于公安局)，所有人都有CA的公钥 工作原理： 1、B向CA机构提交个人信息、注册秘钥信息。 2、CA机构依据注册秘钥生成非对称加密算法秘钥对，并将该密钥对的公钥、个人信息以及经过CA自身私钥加密后的前两个元素的hash值封装成一张数字证书。 3、将生成的数字证书与生成的密钥对的私钥一同反还给 4、B将数字证书发送给A，A拿B的证书去CA官方提供的OCSP服务器检测证书有效性。如有效则A用CA的公钥解密得到数字证书上的hash，将B的个人信息与B的公钥再次做hash后与解密得到的hash比对，如一致则能保证该公钥为B的公钥 | |
| 产生的问题： 如果C拿到B的证书即可冒充A来给B发送数据(反过来也可以说A给B发送了一个数据后A不承认这个数据是A发的)，那么B应该怎么确认发来的数据肯定就是A发的呢？ | |
| 上述问题方案： A也使用数字证书 解决的问题： 不可抵赖性 前提： 参考上述申请数字证书方法也给A申请一张数字证书，同理B也获取了A真实的公钥 工作原理： A将发送给B的hash值用A的私钥进行加密，B用A的公钥对hash进行解密。如果解密后的hash值与'AES+user_passwd+P_DATA'的hash相同，则能证明'AES+user_passwd+P_DATA'确实是A发来的 | |
| 产生的问题： 如果B的私钥丢失，加密文件解不开了怎么办？ | |
| 上述问题方案： 向CA机构申请补发证书 解决问题： 加密文件可挽救 注意： 证书申请时的注册秘钥信息用于补发证书与私钥，故要与证书、私钥分离保存 工作原理： 向CA机构提供原始注册秘钥信息，CA机构根据颁发记录生成一张与原来一致的证书与私钥反还给B | |
| 产生的问题： B的私钥丢失后被C用来解密数据怎么办？ | |
| 上述问题方案： 为私钥使用设立门槛 解决问题： 私钥丢失后的数据私密性保证 场景： 可能数字证书保存在U盘中，此时可对U盘设置密码(PIN码) 工作原理： 为保存私钥的介质加密防止别人拿来就用 |
随着Web2.0、社交网络、微博等等一系列新型的互联网产品的诞生，基于Web环境的互联网应用越来越广泛，企业信息化的过程中各种应用都架设在Web平台上，Web业务的迅速发展也引起黑客们的强烈关注，接踵而至的就是Web安全威胁的凸显，黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞等得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。
一． 输入验证
1. 概述
任何来自客户端的数据，如URL,参数,http头部，都属于不可信任数据。都需要将其当作潜在的恶意输入来进行校验，且校验必须要在可信系统（比如服务器/后端）上进行。
2. 白名单
如果传入参数的取值范围有限，应该有限考虑使用白名单的方式对传入参数进行检测
3. 字符集规范化
为所有输入明确恰当的字符集，建议使用UTF-8
4. 黑名单
不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a,\r, \n)、路径字符(…/ 或 ..\),< ,>, ", ', %, (, ), &, +, \,等,建议直接阻止该数据,若需要接受该数据,必须保证执行了额外的控制(参考二至八)
5. 过滤
不可信数据需实施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或"转义"，包含但不限于<,>,",%,&,+,\,/,"等危险特殊字符
6. 业务合法性校验
对于一些有规则可循的输入，如email地址、日期、小数等，使用正则表达式进行校验。
对于传入数据存在取值范围，需要对取值范围进行控制，如资金数量不能为负，购买金额必须大于某个值等。
7. 访问控制
所有传入参数还应确认所提交的内容是否与用户的身份匹配,避免越权访问
二． 输出处理
1. 概述
对所有输出进行安全并且正确的处理，并且需要在可信系统上执行所有的编码
2. 编码场景
可根据具体场景进行相关编码，如html编码，URL编码等；并且在需要在可信系统（比如：服务器）上执行。
3. 净化场景
针对操作系统命令、SQL和LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等
三． SQL注入防范
1. 概述
用户的输入进入应用程序的SQL操作前,对输入进行合法性校验。
2. 参数化处理
用参数化查询(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter，MyBaits使用#)方法对敏感字符如"进行转义,然后再进行SQL操作
3. 最小化授权
为每个应用配置最小化数据库操作权限,禁止用管理员权限进行数据库操作,限制操作连接数。
4. 禁止错误回显
禁止系统开启 Debug模式或异常时返回包含敏感信息的提示,建议使用自定义的错误信息模板。异常信息应存放在日志中用于安全审计。
四． XSS防御规范
1. 概述
防止用户的输入直接回显在前端，造成XSS攻击
2. 安全编码
需要采用安全的API对数据的输入或者数据的输出进行处理，需要使用 owasp-java-Encoder：https://github.com/OWASP/owasp-java-encoder/releases或AntiSamy https://code.google.com/archive/p/owaspantisamy/downloads
进行数据处理
3. 安全策略
可以在Cookie中引入httponly来保证安全性，也可以通过引入内容安全策略(CSP)阻止跨站脚本的发生
五． 命令注入防范
1. 概述
需要防止攻击者从远端提交到未经过滤的应用中，从而执行包含在恶意数据中的命令
2. 安全编码
当代码中存在执行命令的函数时，需要保证入参不能完全由客户控制，若执行命令有限的情况下，可采取白名单的策略，对于从外部传入的参数，需要过滤|,;,||,&,等
六． XXE防范
1. 概述
防止攻击者提交包含恶意实体的XML代码导致服务器解析后造成XML漏洞
2. 安全编码
使用开发语言提供的禁用外部实体的方法，如php使用libxml_disable_entity_loader，java使用dbf.setExpandEntityReferences
七． CSRF防范
1. 概述
防止攻击者通过CSRF来伪造受害人的操作进行攻击
2. Token使用
在重要操作的表单中增加会话生成的 Token字段一次一用,提交后在服务端校验该字段
3. 二次验证
在关键表单提交时,要求用户进行二次身份验证如密码、图片验证码、短信验证码等
4. Referer验证
检验用户请求中 Referer:字段是否存在跨域提交的情况，如果发现跨域提交，则拒绝该请求
八． 文件上传安全规范
1. 概述
防止攻击者利用上传文件的功能上传恶意内容威胁服务器
2. 身份验证
进行文件上传时,在服务端对用户的身份进行合法性校验，如是否用户具备上权限等
3. 合法性校验
进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。
4. 存储环境设置
进行文件保存时,保存在与应用环境独立的文档服务器中(配置独立域名),保存的目录权限应设置为不可执行
5. 隐藏文件路径
进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。
6. 文件访问设置
进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件直接执行)
九． 身份验证和密码管理
1. 概述
除了那些特定设为“公开”的内容以外，对所有的网页和资源要求身份验证
2. 执行环境
所有的身份验证过程必须在可信系统（比如：服务器而非前端/客户端）上执行
3. 统一实现
在任何可能的情况下，建立并使用标准的、已通过测试的身份验证服务，为所有身份验证控制使用一个集中实现的方法
4. 密码存储
如果应用程序管理着凭证的存储，那么应当保证只保存了通过使用强加密单向 salted 哈希算法得到的密码，并且只有应用程序具有对保存密码和密钥的表/文件的写权限，在哈希算法的选择上选择强哈希算法(如SHA256等)
5. 消息提示
身份验证的失败提示信息应当避免过于明确，比如：可以使用“用户名和/或密码错误”，而不要使用“用户名错误”或者“密码错误”。错误提示信息在显示和源代码中应保持一致
6. 凭据保护
用于访问应用程序以外服务的身份验证凭据信息应当加密，并存储在一个可信系统（比如：服务器）中受到保护的地方。源代码不是一个安全的地方
7. 传输方法
只使用HTTP Post请求传输身份验证的凭据信息
8. 暴力破解防范
当连续多次登录失败后（比如：通常情况下是5次），应强制锁定账户。账户锁定的时间必须足够长，以阻止暴力攻击猜测登录信息，但是不能长到允许执行一次拒绝服务攻击。
9. 时效控制
临时密码和链接应当有一个短暂的有效期。
10. 重置提示
当密码重新设置时，通知用户
11. 重置提示
当密码重新设置成功时，通知用户
12. 二次验证
在执行关键操作以前，对用户再次进行身份验证，如大额转账，支付订单等
13. 多因子验证
为高度敏感或重要的交易账户使用多因子身份验证机制。
十． 会话管理
1. 随机性保证
会话管理控制应当使用通过审查的算法以保证足够的随机会话标识符
2. 会话作用范围
为包含已验证的会话标识符的cookie设置域和路径，以为站点设置一个恰当的限制值
3. 注销
注销功能应当完全终止相关的会话或连接
4. 传输方法限制
不要在URL、错误信息或日志中暴露会话标识符。会话标识符应当只出现在HTTP cookie头信息中。比如，不要将会话标识符以GET参数进行传递
5. 鉴权
通过在服务器上使用恰当的访问控制，保护服务器端会话数据免受来自服务器其他用户的未授权访问
6. Cookie保护
将cookie设置为HttpOnly属性，除非在应用程序中明确要求了客户端脚本程序读取或者设置cookie的值
十一． 访问控制
1. 敏感信息保护
安全的处理访问控制失败的操作，如不要暴露敏感信息
2. 授权控制
i. 限制只有授权的用户才能访问文件或其他资源，包括那些应用程序外部的直接控制
ii. 限制只有授权的用户才能访问受保护的URL
iii. 限制只有授权的用户才能访问受保护的功能
iv. 限制只有授权的用户才能访问直接对象引用
v. 限制只有授权的用户才能访问服务
vi. 限制只有授权的用户才能访问应用程序数据
vii. 限制通过使用访问控制来访问用户、数据属性和策略信息
viii. 限制只有授权的用户才能访问与安全相关的配置信息
3. 服务端二次控制
如果状态数据必须存储在客户端，使用加密算法，并在服务器端检查完整性以捕获状态的改变，对于涉及敏感数据的服务端操作，可以考虑对关键操作进行加锁以用来防止条件竞争漏洞。
十二． 数据保护
1. 最低权限原则
授予最低权限，以限制用户只能访问为完成任务所需要的功能、数据和系统信息
2. 临时数据处理原则
授予最低权限，以限制用户只能访问为完成任务所需要的功能、数据和系统信息
3. 服务端存储保护
即使在服务器端，任然要加密存储的高度机密信息，比如，身份验证的验证数据。
4. 服务端源代码保护
保护服务器端的源代码不被泄露，如禁止将源代码压缩包放在用户可访问目录下，禁止将代码传到网盘或github等公开存储中
5. 客户端信息保护
不要在客户端上以明文形式或其他非加密安全模式保存密码、连接字符串或其他敏感信息
6. 信息最小化原则
删除用户可访问产品中的注释，以防止泄露后台系统或者其他敏感信息
删除不需要的应用程序和系统文档，因为这些也可能向攻击者泄露有用的信息
7. 信息最小化原则
禁止表单中的自动填充功能，因为表单中可能包含敏感信息，包括身份验证信息
8. 禁止表单填充
禁止表单中的自动填充功能，因为表单中可能包含敏感信息，包括身份验证信息
9. 账户信息清除
应用程序应当支持，当数据不再需要的时候，删除敏感信息
10. 敏感信息访问控制
为存储在服务器中的敏感信息提供恰当的访问控制。这包括缓存的数据、临时文件以及只允许特定系统用户访问的数据
十三． H5安全
1. 跨域访问控制
H5中，对跨域操作必须要进行来源验证，如CORS，Postmessage, websocket必须要验证Origin，jsonp必须 要对referer 进行验证
2. 存储安全
i. Localstorage一般是被js设置和读取，但却不能像Cookie一样设置httponly，所以可以配合CORS来获取网站的localstorage的信息，所以locastorage不能存放敏感信息，有必要的话需要对其进行加密处理。
ii. 需要临时保存的变量相比在localStorage中存储更适合在SessionStorage中进行存储。
3. Iframe安全
对于存在敏感信息或敏感操作的页面，开发人员可以通过设置X-Frame-Options返回头进行点击劫持的防御
根据OWASP Top 10，十大安全漏洞是：
SQL Injection（SQL注入）Cross Site Scripting（xss跨站脚本）Broken Authentication and Session Management（身份验证和会话管理中断）Insecure Direct Object References（不安全的直接对象引用）Cross Site Request Forgery（跨站点请求伪造）Security Misconfiguration（安全配置错误）Insecure Cryptographic Storage（不安全的加密存储）Failure to restrict URL Access（无法限制URL访问）Insufficient Transport Layer Protection（传输层保护不足）Unvalidated Redirects and Forwards（未经验证的重定向和转发）
SQL注入
描述 SQL注入是一个安全漏洞，允许攻击者通过操纵用户提供的数据来更改后端SQL语句。 当用户输入作为命令或查询的一部分被发送到解释器并且欺骗解释器执行非预期的命令并且允许访问未授权的数据时，发生注入。 由Web应用程序执行时的SQL命令也可以公开后端数据库。 意义
攻击者可以将恶意内容注入易受攻击的字段。可以从数据库中读取敏感数据，如用户名，密码等。可以修改数据库数据（插入/更新/删除）。管理操作可以在数据库上执行
易受攻击的对象
输入字段与数据库交互的URL。
例子：
登录页面上的SQL注入
在没有有效凭据的情况下登录应用程序。 有效的userName可用，密码不可用。 测试网址：http：//demo.testfire.net/default.aspx 用户名：sjones 密码：1 = 1'或pass123 创建SQL查询并将其发送到Interpreter，如下所示 SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1'或pass123; 建议
白名单列出输入字段避免显示对攻击者有用的详细错误消息。
xss跨站脚本 描述 Cross Site Scripting也简称为XSS。 XSS漏洞针对嵌入在客户端（即用户浏览器而不是服务器端）的页面中嵌入的脚本。当应用程序获取不受信任的数据并将其发送到Web浏览器而未经适当验证时，可能会出现这些缺陷。 在这种情况下受害者浏览器，攻击者可以使用XSS对用户执行恶意脚本。由于浏览器无法知道脚本是否可靠，脚本将被执行，攻击者可以劫持会话cookie，破坏网站或将用户重定向到不需要的恶意网站。 XSS是一种攻击，允许攻击者在受害者的浏览器上执行脚本。 意义：
利用此安全漏洞，攻击者可以将脚本注入应用程序，可以窃取会话cookie，破坏网站，并可以在受害者的计算机上运行恶意软件。
易受攻击的对象
输入字段网址
例子 1. http://www.vulnerablesite.com/home?" < script > alert(" xss") </ script > 上述脚本在浏览器上运行时，如果站点易受XSS攻击，将显示一个消息框。 如果攻击者想要显示或存储会话cookie，则可以进行更严重的攻击。 2. http://demo.testfire.net/search.aspx?txtSearch <iframe > <src = http://google.com width = 500 height 500> </ iframe> 上面的脚本运行时，浏览器会加载一个指向http://google.com的隐形框。 通过在浏览器上运行恶意脚本可以使攻击变得严重。 建议
白名单输入字段输入输出编码
身份验证和会话管理中断 描述 网站通常为每个有效会话创建会话cookie和会话ID，这些cookie包含敏感数据，如用户名，密码等。当会话通过注销或浏览器突然关闭结束时，这些cookie应该无效，即每个会话应该有一个新的cookie。 如果cookie未失效，则敏感数据将存在于系统中。例如，使用公共计算机（Cyber Cafe）的用户，易受攻击的站点的cookie位于系统上并暴露给攻击者。攻击者在一段时间后使用相同的公共计算机，敏感数据会受到损害。 以同样的方式，用户使用公共计算机，而不是注销，他突然关闭浏览器。攻击者使用相同的系统，当浏览同一个易受攻击的站点时，受害者的上一个会话将被打开。攻击者可以通过窃取个人资料信息，信用卡信息等做任何他想做的事情。 应该进行检查以找到身份验证和会话管理的强度。密钥，会话令牌，cookie应该在不影响密码的情况下正确实施。 易受攻击的对象
在URL上公开的会话ID可能导致会话固定攻击。注销和登录前后的会话ID相同。会话超时未正确实施。应用程序为每个新会话分配相同的会话ID。应用程序的经过身份验证的部分使用SSL进行保护，密码以散列或加密格式存储。会话可由低权限用户重用。
意义
利用此漏洞，攻击者可以劫持会话，对系统进行未经授权的访问，从而允许泄露和修改未经授权的信息。使用盗取的cookie或使用XSS的会话可以高举会话。
例子
航空公司预订应用程序支持URL重写，将会话ID放在URL中： http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives（出售马尔代夫门票） 该网站的经过身份验证的用户希望让他的朋友了解该销售并发送电子邮件。朋友收到会话ID，可用于进行未经授权的修改或滥用保存的信用卡详细信息。应用程序容易受到XSS攻击，攻击者可以通过XSS访问会话ID并可用于劫持会话。应用程序超时未正确设置。用户使用公共计算机并关闭浏览器，而不是注销并离开。攻击者稍后使用相同的浏览器，并对会话进行身份验证。
建议
应根据OWASP应用程序安全验证标准定义所有身份验证和会话管理要求。永远不要在URL或日志中公开任何凭据。还应该做出很大的努力来避免可用于窃取会话ID的XSS漏洞。
不安全的直接对象引用 描述 当开发人员公开对内部实现对象的引用（例如URL或FORM参数中的文件，目录或数据库键）时，就会发生这种情况。攻击者可以使用此信息访问其他对象，并可以创建将来的攻击来访问未经授权的数据。 意义
使用此漏洞，攻击者可以访问未经授权的内部对象，可以修改数据或破坏应用程序。
易受攻击的对象
在URL中。
例子： 更改以下URL中的“userid”可以使攻击者查看其他用户的信息。 http://www.vulnerablesite.com/userid=123修改为http://www.vulnerablesite.com/userid=124 攻击者可以通过更改用户标识值来查看其他信息。 建议：
实施访问控制检查。避免在URL中公开对象引用。验证对所有引用对象的授权。
csrf跨站点请求伪造 描述 Cross Site Request Forgery是来自跨站点的伪造请求。 CSRF攻击是指恶意网站，电子邮件或程序导致用户的浏览器在用户当前已对其进行身份验证的受信任站点上执行不需要的操作时发生的攻击。 CSRF攻击强制登录受害者的浏览器向易受攻击的Web应用程序发送伪造的HTTP请求，包括受害者的会话cookie和任何其他自动包含的身份验证信息。 当用户在登录原始网站时点击URL时，攻击者将向受害者发送链接，该数据将从网站上被窃取。 意义
将此漏洞用作攻击者可以更改用户配置文件信息，更改状态，代表管理员创建新用户等。
易受攻击的对象
用户档案页面用户帐户表单商业交易页面
例子 受害者使用有效凭据登录银行网站。他收到攻击者的邮件说“请点击此处捐赠1美元。” 当受害者点击它时，将创建一个有效请求以向特定帐户捐赠1美元。 http://www.vulnerablebank.com/transfer.do?account=cause&amount=1 攻击者捕获此请求并创建以下请求，并嵌入一个按钮，说“我支持原因”。 http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000 由于会话已通过身份验证并且请求通过银行网站发送，因此服务器将向攻击者转移1000美元。 建议
在执行敏感操作时强制用户在场。实现CAPTCHA，重新认证和唯一请求令牌等机制。
安全配置错误 描述 必须为应用程序，框架，应用程序服务器，Web服务器，数据库服务器和平台定义和部署安全性配置。如果这些配置正确，攻击者可能会未经授权访问敏感数据或功能。 有时这种缺陷会导致系统完全妥协。保持软件最新也是很好的安全性。 意义
利用此漏洞，攻击者可以枚举底层技术和应用程序服务器版本信息，数据库信息并获取有关应用程序的信息以进行更多攻击。
易受攻击的对象
网址表格字段输入字段
例子
应用程序服务器管理控制台将自动安装，不会被删除。默认帐户不会更改。攻击者可以使用默认密码登录，并可以获得未经授权的访问。您的服务器上未禁用目录列表。攻击者发现并可以简单地列出目录以查找任何文件。
建议
强大的应用程序架构，可在组件之间提供良好的分离和安全性。更改默认用户名和密码。禁用目录列表并实施访问控制检查。
不安全的加密存储 描述 不安全的加密存储是一种常见的漏洞，在敏感数据未安全存储时存在。 用户凭据，配置文件信息，健康详细信息，信用卡信息等属于网站上的敏感数据信息。 该数据将存储在应用程序数据库中。如果不使用加密或散列*来不正确地存储此数据，则它将容易受到攻击者的攻击。 （* Hashing是将字符串字符转换为固定长度或密钥的较短字符串。要解密字符串，用于形成密钥的算法应该可用） 意义
通过使用此漏洞，攻击者可以窃取，修改此类受弱保护的数据，以进行身份盗用，信用卡欺诈或其他犯罪。
易受攻击的对象
应用数据库。
例子 在其中一个银行应用程序中，密码数据库使用未加保留的哈希*来存储每个人的密码。SQL注入漏洞允许攻击者检索密码文件。所有未加盐的哈希都可以在任何时候强行进行，而盐渍的密码则需要数千年的时间。 （*无盐哈希 - 盐是附加到原始数据的随机数据。在哈希之前将盐附加到密码）
确保适当的强标准算法。不要创建自己的加密算法。仅使用经过批准的公共算法，如AES，RSA公钥加密和SHA-256等。确保异地备份已加密，但密钥是单独管理和备份的。
无法限制URL访问 描述 Web应用程序在呈现受保护的链接和按钮之前检查URL访问权限 每次访问这些页面时，应用程序都需要执行类似的访问控制检查。 在大多数应用程序中，特权页面，位置和资源不会呈现给特权用户。 通过智能猜测，攻击者可以访问权限页面。攻击者可以访问敏感页面，调用函数和查看机密信息。
利用此漏洞攻击者可以访问未经授权的URL，而无需登录应用程序并利用此漏洞。攻击者可以访问敏感页面，调用函数和查看机密信息。
易受攻击的对象：
网址
例子
攻击者注意到URL表示角色为“/ user / getaccounts”。他修改为“/ admin / getaccounts”。攻击者可以将角色附加到URL。
http://www.vulnerablsite.com可以修改为http://www.vulnerablesite.com/admin 建议
实施强大的访问控制检查。身份验证和授权策略应基于角色。限制对不需要的URL的访问。
传输层保护不足 描述 处理用户（客户端）和服务器（应用程序）之间的信息交换。应用程序经常通过网络传输敏感信息，如身份验证详细信息，信用卡信息和会话令牌。 通过使用弱算法或使用过期或无效的证书或不使用SSL，可以允许将通信暴露给不受信任的用户，这可能会危及Web应用程序和/或窃取敏感信息。 意义
利用此Web安全漏洞，攻击者可以嗅探合法用户的凭据并获取对该应用程序的访问权限。可以窃取信用卡信息。
易受攻击的对象
通过网络发送的数据。
建议
启用安全HTTP并仅通过HTTPS强制执行凭据传输。确保您的证书有效且未过期。
例子： 1.不使用SSL的应用程序，攻击者只会监视网络流量并观察经过身份验证的受害者会话cookie。攻击者可以窃取该cookie并执行Man-in-the-Middle攻击。 未经验证的重定向和转发 描述 Web应用程序使用很少的方法将用户重定向并转发到其他页面以实现预期目的。 如果在重定向到其他页面时没有正确的验证，攻击者可以利用此功能，并可以将受害者重定向到网络钓鱼或恶意软件站点，或者使用转发来访问未经授权的页面。 意义
攻击者可以向用户发送包含附加编码恶意URL的真实URL的URL。用户只需看到攻击者发送的URL的真实部分就可以浏览它并可能成为受害者。
例子 1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com 修改为 http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com 建议
只需避免在应用程序中使用重定向和转发。如果使用，请不要在计算目的地时使用用户参数。如果无法避免目标参数，请确保提供的值有效，并为用户授权。
扫一扫
761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
