安全漏洞_安全漏洞检测 - CSDN
  • 安全漏洞概念及分类

    万次阅读 2016-10-12 16:50:58
    本文是一个安全漏洞相关的科普,介绍安全漏洞的概念认识,漏洞在几个维度上的分类及实例展示。 安全漏洞及相关的概念 本节介绍什么是安全漏洞及相关的概况。 安全漏洞的定义 我们经常听到漏洞这个概念,可...
    本文是一个安全漏洞相关的科普,介绍安全漏洞的概念认识,漏洞在几个维度上的分类及实例展示。

    安全漏洞及相关的概念

    本节介绍什么是安全漏洞及相关的概况。

    安全漏洞的定义

    我们经常听到漏洞这个概念,可什么是安全漏洞?想给它一个清晰完整的定义其实是非常困难的。如果你去搜索一下对于漏洞的定义,基本上会发现高大上的学术界和讲求实用的工业界各有各的说法,漏洞相关的各种角色,比如研究者、厂商、用户,对漏洞的认识也是非常不一致的。  
    从业多年,我至今都找不到一个满意的定义,于是我自己定义一个:  

    安全漏洞是信息系统在生命周期的各个阶段(设计、实现、运维等过程)中产生的某类问题,这些问题会对系统的安全(机密性、完整性、可用性)产生影响。

    这是一个从研究者角度的偏狭义的定义,影响的主体范围限定在了信息系统中,以尽量不把我们所不熟悉的对象扯进来。

    漏洞之所以被描述为某种”问题”,是因为我发现无法简单地用脆弱性、缺陷和Bug等概念来涵盖它,而更象是这些概念的一个超集。    
    漏洞会在系统生命周期内的各个阶段被引入进来,比如设计阶段引入的一个设计得非常容易被破解加密算法,实现阶段引入的一个代码缓冲区溢出问题,运维阶段的一个错误的安全配置,这些都有可能最终成为漏洞。     
    定义对安全的影响也只涉及狭义信息安全的三方面:机密性、完整性和可用性。漏洞造成的敏感信息泄露导致机密性的破坏;造成数据库中的信息被非法篡改导致完整性的破坏;造成服务器进程的崩溃导致可用性的丧失。漏洞也可能同时导致多个安全属性的破坏。

    安全漏洞与Bug的关系

    漏洞与Bug并不等同,他们之间的关系基本可以描述为:大部分的Bug影响功能性,并不涉及安全性,也就不构成漏洞;大部分的漏洞来源于Bug,但并不是全部,它们之间只是有一个很大的交集。可以用如下这个图来展示它们的关系

    安全漏洞概念及分类

    已知漏洞的数量

    各个漏洞数据库和索引收录了大量已知的安全漏洞,下表是一个主流漏洞库的数量的大致估计,漏洞一般最早从20世纪90年代开始:

    漏洞条目库

    特点

    数量 URL
    SecurityFocus 全揭露,带POC >60000 http://www.securityfocus.com/bid/
    OSVDB 数量最大,索引丰富 >100000 http://www.osvdb.org/
    Secunia 产品分类细 >58000 http://secunia.com/community/advisories/
    ISS XForce 描述信息专业 >90000 http://xforce.iss.net/
    CVE 最全的索引 >60000 http://cve.mitre.org/cve/cve.html
    CNVD 国内的中文数据库 >60000 http://www.cnvd.org.cn/flaw/list.htm

    事实上,即便把未知的漏洞排除在外,只要订了若干漏洞相关的邮件列表就会知道:并不是所有漏洞数据库都会收录,就算把上面的所列的数据库中的所有条目加起来去重以后也只是收录了一部分的已知漏洞而已,实际的已知漏洞数比总收录的要高得多。

    安全漏洞的分类

    和其他事物一样,安全漏洞具有多方面的属性,也就可以从多个维度对其进行分类,重点关注基于技术的维度。注意,下面提到的所有分类并不是在数学意义上严格的,也就是说并不保证同一抽象层次、穷举和互斥,而是极其简化的出于实用为目的分类。

    基于利用位置的分类

    本地漏洞

    需要操作系统级的有效帐号登录到本地才能利用的漏洞,主要构成为权限提升类漏洞,即把自身的执行权限从普通用户级别提升到管理员级别。

    实例:

    Linux Kernel 2.6 udev Netlink消息验证本地权限提升漏洞( CVE-2009-1185 )

    攻击者需要以普通用户登录到系统上,通过利用漏洞把自己的权限提升到root用户,获取对系统的完全控制。

    远程漏洞

    无需系统级的帐号验证即可通过网络访问目标进行利用,这里强调的是系统级帐号,如果漏洞利用需要诸如FTP用户这样应用级的帐号要求也算是远程漏洞。   
    实例:

    -  Microsoft Windows DCOM RPC接口长主机名远程缓冲区溢出漏洞(MS03-026)(CVE-2003-0352)   
    攻击者可以远程通过访问目标服务器的RPC服务端口无需用户验证就能利用漏洞,以系统权限执行任意指令,实现对系统的完全控制。 

    基于威胁类型的分类

    获取控制

    可以导致劫持程序执行流程,转向执行攻击者指定的任意指令或命令,控制应用系统或操作系统。威胁最大,同时影响系统的机密性、完整性,甚至在需要的时候可以影响可用性。   
    主要来源:内存破坏类、CGI类漏洞

    获取信息

    可以导致劫持程序访问预期外的资源并泄露给攻击者,影响系统的机密性。   
    主要来源:输入验证类、配置错误类漏洞

    拒绝服务

    可以导致目标应用或系统暂时或永远性地失去响应正常服务的能力,影响系统的可用性。   
    主要来源:内存破坏类、意外处理错误处理类漏洞。  

    基于技术类型的分类   

    基于漏洞成因技术的分类相比上述的两种维度要复杂得多,对于目前我所见过的漏洞大致归纳为以下几类:

    - 内存破坏类
    - 逻辑错误类
    - 输入验证类
    - 设计错误类
    - 配置错误类

    以下是对这几类漏洞的描述和实例分析。

    内存破坏类

    此类漏洞的共同特征是由于某种形式的非预期的内存越界访问(读、写或兼而有之),可控程度较好的情况下可执行攻击者指定的任意指令,其他的大多数情况下会导致拒绝服务或信息泄露。   
    对内存破坏类漏洞再细分下来源,可以分出如下这些子类型:

    - 栈缓冲区溢出
    - 堆缓冲区溢出
    - 静态数据区溢出
    - 格式串问题
    - 越界内存访问
    - 释放后重用
    - 二次释放
    栈缓冲区溢出

    最古老的内存破坏类型。发生在堆栈中的缓冲区溢出,由于利用起来非常稳定,大多可以导致执行任意指令,威胁很大。此类漏洞历史非常悠久, 1988年著名的Morris蠕虫传播手段之一就是利用了finger服务的一个栈缓冲区溢出漏洞。在2008年之前的几乎所有影响面巨大的网络蠕虫也基本利用此类漏洞,汇总情况可以见下表: 

    蠕虫 中文名号 MS 公告号  CVE ID 漏洞名
    Slammer 蠕虫王 MS02-056 CVE-2002-1123 Microsoft SQL Server预验证过程远程缓冲区溢出漏洞
    MSBlast 冲击波 MS03-026 CVE-2003-0352 Microsoft Windows DCOM RPC接口长主机名远程缓冲区溢出漏洞
    Sasser 震荡波 MS04-011 CVE-2003-0533 Microsoft Windows LSASS远程缓冲区溢出漏洞
    Conficker 飞客蠕虫 MS08-067 CVE-2008-4250 Microsoft Windows Server服务RPC请求缓冲区溢出漏洞

    上面表格里列出的蠕虫即使经过多年,在当前的互联网上还经常被捕捉到。   栈溢出漏洞是相对比较容易发现的漏洞,静态动态分析的方法对于此漏洞的挖掘已经相当成熟,因此这类漏洞,特别是服务端程序中,目前基本处于日渐消亡的状态。   实例:
    - 暴风影音stormtray进程远程栈缓冲区溢出漏洞
    长度检查不充分的串连接操作。

    安全漏洞概念及分类

    - Sun Solaris snoop(1M)工具远程指令执行漏洞( CVE-2008-0964 )

    无长度检查的*printf调用。

    安全漏洞概念及分类

    frameborder="0" allowtransparency="true" scrolling="no" vspace="0" hspace="0" style="position: static; display: block; padding: 0px; margin: 0px; border-style: none; vertical-align: baseline; width: 341px; height: 74px;">

    - Novell eDirectory HTTPSTK Web服务器栈溢出漏洞

    无长度检查的memcpy调用。

    安全漏洞概念及分类

    frameborder="0" allowtransparency="true" scrolling="no" vspace="0" hspace="0" style="position: static; display: block; padding: 0px; margin: 0px; border-style: none; vertical-align: baseline; width: 342px; height: 74px;">

    - FlashGet FTP PWD命令超长响应栈溢出漏洞

    安全漏洞概念及分类

    - Imatix Xitami If-Modified-Since头远程栈溢出漏洞。

    极其危险的sscanf类调用。

    安全漏洞概念及分类

    - Borland StarTeam Multicast服务用户请求解析远程栈溢出漏洞( CVE-2008-0311 )

    安全漏洞概念及分类

    - Microsoft DirectShow MPEG2TuneRequest 溢出漏洞( CVE-2008-0015 )

    手抖,缓冲区的指针被当做缓冲区本身被数据覆盖溢出。

    安全漏洞概念及分类

    堆缓冲区溢出

    导致堆缓冲区溢出的来源与栈溢出的一致,基本都是因为一些长度检查不充分的数据操作,唯一不同的地方只是发生问题的对象不是在编译阶段就已经确定分配的栈缓冲区,而是随着程序执行动态分配的堆块。   
    实例:
    - HP OpenView NNM Accept-Language HTTP头堆溢出漏洞( CVE-2009-0921)
    典型的先分配后使用的堆溢出问题。

    安全漏洞概念及分类

    PHP (phar extension)堆溢出漏洞

    堆溢出特有的溢出样式:由于整数溢出引发Malloc小缓冲区从而最终导致堆溢出。

    安全漏洞概念及分类

    静态数据区溢出

    发生在静态数据区BSS段中的溢出,非常少见的溢出类型。

    实例:

    - Symantec pcAnyWhere awhost32远程代码执行漏洞(CVE-2011-3478)

    安全漏洞概念及分类

    格式串问题

    在*printf类调用中由于没有正确使用格式串参数,使攻击者可以控制格式串的内容操纵*printf调用越界访问内存。此类漏洞通过静态或动态的分析方法可以相对容易地被挖掘出来,因此目前已经很少能够在使用广泛的软件中看到了。

    实例:

    - Qualcomm Qpopper 2.53格式串处理远程溢出漏洞(CVE-2000-0442)

    安全漏洞概念及分类

    想了解更多格式串漏洞的原理和利用,可以参考warning3在很早之前写的文档:

    *printf()格式化串安全漏洞分析 http://www.nsfocus.net/index.php?act=magazine&do=view&mid=533http://www.nsfocus.net/index.php?act=magazine&do=view&mid=534<喎�"/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxoNj4NCgk8c3Ryb25nPtS9vefE2rTmt8POyjwvc3Ryb25nPjwvaDY+DQo8cD6zzNDyw6TEv9DFyM7AtNfUzajQxbbUt720q7XdtcTK/b7do6yyotLUtMvX986qxNq05rfDzsq1xMv30v2jrLv70M61xMr91rW1vNbC1L2957XExNq05rfDzsqjrNTss8nE2rTmxsa7tbvy0MXPotC5wrahoyZuYnNwOyAmbmJzcDs8YnIgLz4NCsq1wP2jujxiciAvPg0KLSBPcGVuU1NMIFRMU9DEzPjAqdW50K3S6bD81LazzNDFz6LQucK2wqm2tCAoQ1ZFLTIwMTQtMDE2MCk8YnIgLz4NCsKptrTKx9PJ09q9+LPMsru807zssum12Mq508PNqNDFttS2y8zhuam1xMr9vt3H+LOktsjWtaOssLTWuLaotcSzpLbItsHIocTatOa3tbvYo6y1vNbC1L2957fDzsq1vbTzv+m1xNSkxtrS1M3itcTE2rTmyv2+3bKit7W72KOs0LnCtrD8wKjTw7unw/uhor/awe6holNlc3Npb25JRMn11sHKx8u91L+1yNTaxNq1xMP0uNDQxc+ioaM8L3A+DQo8cD48aW1nIGFsdD0="安全漏洞概念及分类" src="/uploadfile/2014/0508/20140508110216384.png" style="display: block;" />

    释放后重用

    这是目前最主流最具威胁的客户端(特别是浏览器)漏洞类型,大多数被发现的利用0day漏洞进行的水坑攻击也几乎都是这种类型,每个月各大浏览器厂商都在修复大量的此类漏洞。技术上说,此类漏洞大多来源于对象的引用计数操作不平衡,导致对象被非预期地释放后重用,进程在后续操作那些已经被污染的对象时执行攻击者的指令。与上述几类内存破坏类漏洞的不同之处在于,此类漏洞的触发基于对象的操作异常,而非基于数据的畸形异常(通常是不是符合协议要求的超长或畸形字段值),一般基于协议合规性的异常检测不再能起作用,检测上构成极大的挑战。   
    实例:
    - Microsoft IE非法事件操作内存破坏漏洞(CVE-2010-0249)
    著名的Aurora攻击,涉嫌入侵包括Google在内的许多大互联网公司的行动,就使用了这个CVE-2010-0249这个典型的释放后重用漏洞。

    安全漏洞概念及分类

    二次释放

    一般来源于代码中涉及内存使用和释放的操作逻辑,导致同一个堆缓冲区可以被反复地释放,最终导致的后果与操作系统堆管理的实现方式相关,很可能实现执行任意指令。

    实例:

    - CVS远程非法目录请求导致堆破坏漏洞( CVE-2003-0015)

    安全漏洞概念及分类

    逻辑错误类

    涉及安全检查的实现逻辑上存在的问题,导致设计的安全机制被绕过。

    实例:

    - Real VNC 4.1.1验证绕过漏洞( CVE-2006-2369 )

    漏洞允许客户端指定服务端并不声明支持的验证类型,服务端的验证交互代码存在逻辑问题。

    安全漏洞概念及分类

    安全漏洞概念及分类

    Android应用内购买验证绕过漏洞

    Google Play的应用内购买机制的实现上存在的漏洞,在用户在Android应用内购买某些数字资产时会从Play 市场获取是否已经付费的验证数据,对这块数据的解析验证的代码存在逻辑问题,导致攻击者可以绕过验证不用真的付费就能买到东西。验证相关的代码如下:

    安全漏洞概念及分类

    代码会先检查回来的数据签名是否为空,不空的话检查签名是否正确,如果不对返回失败。问题在于如果签名是空的话并没有对应的else逻辑分支来处理,会直接执行最下面的return true操作,导致的结果是只要返回的消息中签名为空就会返回验证通过。

    输入验证类

    漏洞来源都是由于对来自用户输入没有做充分的检查过滤就用于后续操作,绝大部分的CGI漏洞属于此类。所能导致的后果,经常看到且威胁较大的有以下几类:  

    - SQL注入
    - 跨站脚本执行
    - 远程或本地文件包含
    - 命令注入
    - 目录遍历
    SQL注入

    Web应用对来自用户的输入数据未做充分检查过滤,就用于构造访问后台数据库的SQL命令,导致执行非预期的SQL操作,最终导致数据泄露或数据库破坏。   
    实例:
    - 一个网站Web应用的数值参数的SQL注入漏洞。

    安全漏洞概念及分类

    跨站脚本执行(XSS)

    Web应用对来自用户的输入数据未做充分检查过滤,用于构造返回给用户浏览器的回应数据,导致在用户浏览器中执行任意脚本代码。   
    实例: YouTube上的一个存储式XSS漏洞。

    安全漏洞概念及分类

    远程或本地文件包含

    安全漏洞概念及分类安全漏洞概念及分类

    如果Web应用支持在URL参数中指定服务器上的一个文件执行一些处理,对来自客户端URL数据及本地资源的访问许可如果未做充分的检查,攻击者可能通过简单的目录遍历串使应用把Web主目录以外的系统目录下的文件包含进来,很可能导致信息泄露。   
    实例:
    - 一个网站存在的本地文件包含的漏洞

    安全漏洞概念及分类

    命令注入

    涉及系统命令调用和执行的函数在接收用户的参数输入时未做检查过滤,或者攻击者可以通过编码及其他替换手段绕过安全限制注入命令串,导致执行攻击指定的命令。   实例:
    - AWStats 6.1及以下版本configdir变量远程执行命令漏洞( CVE-2005-0116 )
    典型的由于Perl语言对文件名特性的支持加入未充分检查用户输入的问题,导致的命令注入漏洞,awstats.pl的1082行:if (open(CONFIG,”$searchdir$PROG.$SiteConfig.conf”)) 。

    安全漏洞概念及分类

    目录遍历

    涉及系统用于生成访问文件路径用户输入数据时未做检查过滤,并且对最终的文件绝对路径的合法性检查存在问题,导致访问允许位置以外的文件。多见于CGI类应用,其他服务类型也可能存在此类漏洞。

    实例:

    -  Novell Sentinel Log Manager “filename”参数目录遍历漏洞( CVE-2011-5028 )

    http://www.example.com/novelllogmanager/FileDownload?filename=/opt/novell/sentinel_log_mgr/3rdparty/tomcat/temp/../../../../../../etc/passwd

    -  HP Data Protector Media Operations DBServer.exe目录遍历漏洞

    在HP Data protecetor Media Operations的客户端连接服务端时,通过私访有的通信协议,客户端会首先检查[系统分区]:/Documents and Settings/[用户名]/Application Data下面是否有相应的资源(如插件等),如果没有,则会向服务器请求需要的文件,服务器没有验证请求的文件名的合法性,而且这个过程不需要任何验证,攻击者精心构造文件名,可以读取服务端安装目录所在分区的任意文件。

    安全漏洞概念及分类

    - RHINOSOFT SERV-U FTP SERVER远程目录遍历漏洞

    安全漏洞概念及分类

    Caucho Resin远程目录遍历漏洞

    安全漏洞概念及分类

    设计错误类

    系统设计上对安全机制的考虑不足导致的在设计阶段就已经引入的安全漏洞。

    实例:

    -  LM HASH算法脆弱性

    安全漏洞概念及分类

    这个算法至少存在以下3方面的弱点:

    1、口令转换为大写极大地缩小了密钥空间。
    2、切分出的两组数据分别是独立加密的,暴力破解时可以完全独立并行。
    3、不足7字节的口令加密后得到的结果后半部分都是一样的固定串,由此很容易判定口令长度。

    这些算法上的弱点导致攻击者得到口令HASH后可以非常容易地暴力猜测出等价的明文口令。

     -   Microsoft Windows图形渲染引擎WMF格式代码执行漏洞(MS06-001) (CVE-2005-4560)

        如果一个WMF文件的StandardMetaRecord中,Function 被设置为 META_ESCAPE而Parameters[0] 等于SETABORTPROC,PlayMetaFileRecord()就会调用Escape()函数,Escape()调用SetAbortProc()将自己的第四形参设置为一个回调函数,把图像文件中包含的一个数据块象Shellcode那样执行。此漏洞从Windows 3.1一直影响到2003,攻击者只要让用户处理恶意的WMF文件(通过挂马或邮件)在用户系统上执行任意指令,漏洞实在是太好用影响面太大了,以至有人认为这是一个故意留的后门,其实影响设计的功能是处理打印任务的取消,功能已经被废弃,但废弃的代码并没有移除而导致问题。

      – 搜狐邮箱密码找回功能

        密码找回功能在要求用户提供找回密码需要的问题答案时,在返回给用户的页面中就已经包含了答案,只要通过查看页面源码就能看到,使这个找回密码功能的安全验证完全形同虚设,攻击者由此可以控制任意邮箱。之所以这么设计,可能就是为了尽可能地少对数据库的查询,而把用户帐号安全根本不放在心上。

    安全漏洞概念及分类

      – 紫光输入法用户验证绕过漏洞

    这是类似于2000年微软输入法漏洞的例子,通过访问输入法设置的某些功能绕过操作系统的用户验证执行某些操作。

    安全漏洞概念及分类

    配置错误类

    系统运维过程中默认不安全的配置状态,大多涉及访问验证的方面。

    实例:

      – JBoss企业应用平台非授权访问漏洞( CVE-2010-0738 )

    对控制台访问接口的访问控制默认配置只禁止了HTTP的两个主要请求方法GET和POST,事实上HTTP还支持其他的访问方法,比如HEAD,虽然无法得到的请求返回的结果,但是提交的命令还是可以正常执行的。

    安全漏洞概念及分类

    展开全文
  • 常见安全漏洞

    2018-06-27 19:53:18
    1、SQL注入许多网站程序在编写时,没有对用户输入数据的合法性进行判断,使应用程序存在安全隐患。用户可以提交一段数据库查询代码,(一般是在浏览器地址栏进行,通过正常的www端口访问)根据程序返回的结果,获得...
    1、SQL注入
    许多网站程序在编写时,没有对用户输入数据的合法性进行判断,使应用程序存在安全隐患。用户可以提交一段数据库查询代码,(一般是在浏览器地址栏进行,通过正常的www端口访问)根据程序返回的结果,获得某些他想得知的数据,这就是所谓的SQL Injection ,即SQL注入。
    其主要危害有:在未经授权状况下操作数据库中的数据;恶意篡改网页内容;私自添加系统帐号或者是数据库使用者帐号;网页挂木马等。

    SQL注入被广泛用于非法入侵网站服务器,获取网站控制权。它是应用层上的一种安全漏洞。通常在设计存在缺陷的程序中,对用户输入的数据没有做好过滤,导致恶意用户可以构造一些SQL语句让服务器去执行,从而导致数据库中的数据被窃取,篡改,删除,以及进一步导致服务器被入侵等危害。

    2 、XSS
    XSS又叫CSS (Cross Site Script) ,跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意攻击用户的特殊目的。
    其主要危害有:攻击者通常会在有漏洞的程序中插入 JavaScript、VBScript、ActiveX或Flash以欺骗用户。一旦得手,他们可以盗取用户帐户,修改用户设置,盗取/污染cookie,做虚假广告等。

    发生在客户端DOM(Document Object Model文档对象模型)DOM是一个与平台、编程语言无关的接口,它允许程序或脚本动态地访问和更新文档内容、结构和样式,处理后的结果能够成为显示页面的一部分。DOM中有很多对象,其中一些是用户可以操纵的,如uRI ,location,refelTer等。客户端的脚本程序可以通过DOM动态地检查和修改页面内容,它不需要提交数据到服务器端,而从客户端获得DOM中的数据在本地执行,如果DOM中的数据没有经过严格确认,就会产生DOM XSS漏洞


    3、 信息泄露

    信息泄露是指应用程序泄露应该保密的信息,例如客户端注释中泄露敏感信息、系统日志泄露敏感信息等。这些泄露的信息可能会对攻击者进一步了解应用程序,以致攻击应用程序提供一定的帮助。


    用户认证信息明文传输: 用户认证信息不是通过https加密信道传输,导致用户名密码等敏感信息泄露。

    4、 越权漏洞
    越权漏洞是指由于应用程序未正确实现授权功能,造成用户可以执行其没有资格执行的操作,包括可以查看或修改他本身没资格查看或修改的资源,以及可以执行用户本身没有的功能。


    5、 暴力破解
    暴力破解是一种针对于密码的破译方法,即将密码进行逐个推算直到找出真正的密码为止。攻击者利用该漏洞可以破解存在该漏洞的应用程序的用户密码。


    6、 文件上传漏洞
    文件上传漏洞是由于程序员在对用户文件上传部分的控制不足或者处理缺陷,而导致的用户可以越过其本身权限向服务器上上传可执行的动态脚本文件。恶意攻击者利用该漏洞可以直接向服务器上传一个 webshell( 又称 ASP 木马、PHP 木马等即利用服务器端的文件操作语句写成的动态网页,可以用来编辑你服务器上的文件 ),从而控制该网站。


    7、 CSRF
    跨站请求伪造(CSRF)是 Web 应用程序一种常见的漏洞,其攻击特性是危害性大但非常隐蔽,尤其是在大量 Web 2.0 技术的应用的背景下,CSRF 攻击完全可以在用户法毫无察觉的情况下发起攻击。发起的目标都是通过伪造一个用户请求,该请求不是用户想发出去的请求,而对服务器或服务来说这个请求是完全合法的一个请求,但是却完成了一个攻击者所期望的操作,比如添加一个用户到管理者的群组中,或将一个用户的现金转到另外的一个帐户中。


    8、 路径遍历漏洞
    许多功能强迫Web应用程序根据用户在请求中提交的参数向文件系统读取或写入数据。如果以不安全的方式执行这些操作,攻击者就可以提交专门设计的输入,使得应用程序访问开发者并不希望他访问的文件,这就是路径遍历漏。攻击者可利用这种缺陷读取密码和应用程序日志之类的敏感数据,或者复写安全性至关重要的数据项,如配置文件和软件代码。在最为严重的情况下,这种漏洞可使攻击者能够完全攻破应用程序与基础操作系统。


    9 、服务器开启了不安全的http方法

    OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法,客户端可以在采取具体资源请求之前,决定对该资源采取何种必要措施,或者了解服务器的性能。开启该方法有可能泄漏一些敏感信息,为攻击者发起进一步攻击提供信息。

    TRACE_Method是HTTP(超文本传输)协议定义的一种协议调试方法,该方法会使服务器原样返回任意客户端请求的任何内容。由于该方法会原样返回客户端提交的任意数据,因此可以用来进行跨站脚本(简称XSS)攻击,这种攻击方式又称为跨站跟踪攻击(简称XST)。


    注:转载自:https://blog.csdn.net/netuser1937/article/details/53738737

    展开全文
  • JS中常见的安全漏洞

    千次阅读 2018-08-26 11:25:08
    1、基于DOM的跨站点脚本编制(XSS) ①XSS(Cross Site Script):跨站点脚本编制,指的是攻击者向合法的web页面插入...例如:攻击者在论坛中放一个看似安全得连接,骗取用户点击之后,盗取cookies得用户隐私信...

     

    1、基于DOM的跨站点脚本编制(XSS)

    ①XSS(Cross Site Script):跨站点脚本编制,指的是攻击者向合法的web页面插入恶意的脚本代码(通常是是HTML代码和JS代码),然后提交给服务器,随即服务器响应页面(被植入的恶意脚本代码),攻击者可以利用这些恶意脚本代码进行会话挟持登攻击。例如:攻击者在论坛中放一个看似安全得连接,骗取用户点击之后,盗取cookies得用户隐私信息。

    ②XSS通常被分为:反射型和持久型

    反射型:恶意代码请求的数据在服务器中呈现为未编码和未过滤

    持久性:恶意代码请求的数据被保存在服务器中,每次用户访问这个页面时,恶意代码都会被执行。

    第三类基于DOM的跨站点脚本编制不依赖服务器端的内容,比如HTML页面使用了document.location、document.URL、或者document.referer等DOM元素的属性,攻击者可以利用这些属性植入恶意脚本。

    ③XSS防范方法

    • 代码里对用户输入的地方需要仔细检查长度和对“<”“>”“,”“'”等字符串做过滤;
    • 任何内容写到页面之前都必须加以encode,避免不小心把html tag弄出来;
    • 避免直接在cookie中泄露用户隐私,例如email、密码等
    • 如果网站不需要在浏览器对cookie进行操作,可以在set-cookie末尾加上HttpOnly来防止js代码直接获取cookie
    • 尽量采用post而不是get提交表单

     

    2、CSRF

    (cross-site- request forgery)跨站点请求伪造

    xss是获取信息,不需要提前知道其他用户页面的代码和数据包

    csrf是代替用户完成指定的动作,需要知道其他用户页面的代码和数据包

    ①crsf攻击原理

    • 用户C打开浏览器,访问受信任网站A,输入用户名和密码登录网站A
    • 在用户信息通过验证之后,网站A产生cookie信息并返回给浏览器,这时用户登录网站A成功,可以正常发送求请求到网站A
    • 用户未退出网站A之前,在同一浏览器中,打开一个页面访问网站B
    • 网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问网站A
    • 用户在接收到B返回的攻击性代码后,在不知情的情况下携带cookie信息,向网站A发送请求。而网站A不知道这个请求其实是B发的(误认为是用户发的),会根据用户C的cookie的信息以C的权限处理该请求,导致网站B的恶意代码被执行

    ②crsf攻击实例(转)

        受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下,该请求发送到网站后,服务器会先验证该请求是否来自一个合法的 session,并且该 session 的用户 Bob 已经成功登陆。
            黑客 Mallory 自己在该银行也有账户,他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob,他不能通过安全认证,因此该请求不会起作用。

        这时,Mallory 想到使用 CSRF 的攻击方式,他先自己做一个网站,在网站中放入如下代码: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”,并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时,上述 url 就会从 Bob 的浏览器发向银行,而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下,该请求会失败,因为他要求 Bob 的认证信息。但是,如果 Bob 当时恰巧刚访问他的银行后不久,他的浏览器与银行网站之间的 session 尚未过期,浏览器的 cookie 之中含有 Bob 的认证信息。这时,悲剧发生了,这个 url 请求就会得到响应,钱将从 Bob 的账号转移到 Mallory 的账号,而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了,即使他去银行查询日志,他也只能发现确实有一个来自于他本人的合法请求转移了资金,没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

    ③防御csrf攻击

    三种策略:验证HTTP Referer字段,在请求地址中添加token并验证,在http头中自定义属性并验证

    验证HTTP Referer字段

           在http头部的referer字段中,记录了该http请求的来源地址。在通常情况下,访问一个安全受限页面的请求来自于同一个网站,比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory,用户必须先登陆 bank.example,然后通过点击页面上的按钮来触发转账事件。这时,该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL,通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击,他只能在他自己的网站构造请求,当用户通过黑客的网站发送请求到银行时,该请求的 Referer 是指向黑客自己的网站。因此,要防御 CSRF 攻击,银行网站只需要对于每一个转账请求验证其 Referer 值,如果是以 bank.example 开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer 是其他网站的话,则有可能是黑客的 CSRF 攻击,拒绝该请求。

    缺点:

     

    • referer的值是由浏览器提供的,我们并不能保障浏览器自身没有漏洞,而且目前已经有一些方法可以篡改referer值
    • 用户可以设置浏览器发送时不提供referer,当他们正常访问银行网站时,网站会因为请求没有referer而认为是csrf攻击,拒绝合法用户的请求

    在请求地址中添加token并验证

           CSRF 攻击之所以能够成功,是因为黑客可以完全伪造用户的请求,该请求中所有的用户验证信息都是存在于 cookie 中,因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF,关键在于在请求中放入黑客所不能伪造的信息,并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token,并在服务器端建立一个拦截器来验证这个 token,如果请求中没有 token 或者 token 内容不正确,则认为可能是 CSRF 攻击而拒绝该请求。
            这种方法要比检查 Referer 要安全一些,token 可以在用户登陆后产生并放于 session 之中,然后在每次请求时把 token 从 session 中拿出,与请求中的 token 进行比对,但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求,token 将附在请求地址之后,这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说,要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>,这样就把 token 以参数的形式加入请求了。但是,在一个网站中,可以接受请求的地方非常多,要对于每一个请求都加上 token 是很麻烦的,并且很容易漏掉,通常使用的方法就是在每次页面加载时,使用 javascript 遍历整个 dom 树,对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求,但是对于在页面加载之后动态生成的 html 代码,这种方法就没有作用,还需要程序员在编码时手动添加 token。

             缺点:

            难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站,黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token,黑客可以在自己的网站上得到这个 token,并马上就可以发动 CSRF 攻击。为了避免这一点,系统可以在添加 token 的时候增加一个判断,如果这个链接是链到自己本站的,就在后面添加 token,如果是通向外网则不加。不过,即使这个 csrftoken 不以参数的形式附加在请求之中,黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

    在http头中自定义属性并验证

        这种方法也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便,同时,通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。

        缺点:

     

    •         XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,而且通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便。
    •         对于没有进行 CSRF 防护的遗留系统来说,要采用这种方法来进行防护,要把所有请求都改为 XMLHttpRequest 请求,这样几乎是要重写整个网站,这代价无疑是不能接受的。

    3、基于URL的重定向

    指的是web页面会采用HTTP参数来保存URL,且web页面的脚本会将请求重定向到该保存的URL上,攻击者可以将HTTP中保存的URL改为恶意站点

    4、客户端JS Cookie引用

    • cookie由服务器创建,并存储在客户端浏览器,保存用户的身份识别、session信息、甚至授权信息等。
    • 客户端js可以操作cookie数据
    • 如果在客户端使用JS创建或者修改站点的cookie,那么攻击者就可以查看这些代码,然后根据逻辑修改cookie。一旦cookie中边包含重要的信息,攻击者很容易利用这些漏洞进行特权升级等

    5、JS劫持

    • 许多的应用程序利用JSON作为AJAX的数据传输机制,这通常会收到JS挟持攻击。
    • JSON实际就是一段JS代码,通常是数组格式
    • 攻击者在其恶意站点的网页中通过<script>标签调用被攻击站点的JSON动态数据接口,通过JS Function Hook等技术获得这些JSON数据。

     

     

    展开全文
  • 网站10大常见安全漏洞及解决方案

    万次阅读 2018-05-30 21:04:42
    一般来说牛逼点的地方都会通过安全设备来确保网络环境的安全,所以之前我们也都认为程序员不需要过多的考虑网站安全问题。实际上随着做了几个事业单位的网站之后,也逐渐发现有些方面还是需要程序员注意的。1. SQL...

    一般来说牛逼点的地方都会通过安全设备来确保网络环境的安全,所以之前我们也都认为程序员不需要过多的考虑网站安全问题。实际上随着做了几个事业单位的网站之后,也逐渐发现有些方面还是需要程序员注意的。

    1. SQL注入 安全等级★★★★★

    几乎每一个网站后台开发人员都听到的一个词,并且都很敏感,但是不知道是什么原因造成的很多程序员却在实际开发过程中经常忽视这个问题。前段时间部门一位新同事,据说是5年工作经验,在对他的代码做评审时,我们发现所有的DAO层实现都是直接拼接SQL和参数,总监多次提醒他这个问题,但他也没有发现,直到总监说出SQL注入这个词。

    实际上这个漏洞很严重,一旦被注入成功,后果不堪设想,但这类问题处理起来还是蛮简单的,下面以JAVA为例举例说明

    方案一: 编写拦截器过滤请求(不推荐),此方案建议只在对维护中项目或者代码结构比较乱的情况下使用,底层不容易修改或者不方便修改。此方案效率低,效果也不佳。

    /**
     * 校验参数,判断是否包含sql关键字表达式
     * 此方法会有误伤
     */ 
      
        private static boolean sqlValidate(String str) {  
            str = str.toLowerCase();//统一转为小写  
            String badSqlStr = "'|exec|execute|insert|select|delete|update|count|drop|chr|mid|master|truncate|char|declare|sitename|net user|xp_cmdshell|create|drop|"
                                 +"table|from|grant|use|group_concat|column_name|1=1|=|"   
                                 +"information_schema.columns|table_schema|union|where|*|"  
                              +"chr|mid|master|truncate|char|declare|or|;|,|like|//|/|%|#|-|--|+|";
            String badXssStr = "frame|iframe|script|javascript|=|<|>";
            
            //sql 关键词 有空格分隔
            String[] badSqlStrs = badSqlStr.split("\\|");  
            for (int i = 0; i < badSqlStrs.length; i++) {  
                if (str.indexOf(" "+badSqlStrs[i]) >= 0 || str.indexOf(badSqlStrs[i]+" ") >= 0) {  
                    return true;  
                }  
            }
     
            } 
            
            return false;  
    }


    方案二:推荐方案,使用预编译的prepareStatement代替statement;使用框架中的setParameter设置参数,此方案可有效处理SQL注入问题。

    @Override
          public List<NewsColumn> getColumnListByType(String columnType) {
                String jql = " FROM "+NewsColumn.class.getName(,)+" WHERE type=:type ";
                List<NewsColumn> list = entityManager.createQuery(jql).setParameter("type", columnType).getResultList();
                return list;
          }


    2. 验证码必须后台校验  安全等级★★★★

    前段时间一客户说后台管理看到了一堆这样用户,/etc/init.d  /1=1  ./././ …. Windows/ ,本该截图的,后来处理了就给忘了~~~~,反正从注册内容来看,可以确定两点,通过注册机注册,想通过注册注入攻击。

    通过机器注册:直接跳过了前端的表单校验,而恰巧这个项目在开发的时候,验证码只在前端做了校验,提交到后台没有做再一次的校验,也就是这个漏洞导致了这堆垃圾注册。

    解决方案:前台提交数据到后台后做进一步校验,如验证码校验、数据格式校验、验重校验。

    回想我也曾经用过这个漏洞…老东家海航集团2014年的时候,OA系统添加了登录需要手机短信验证,当时系统更新后第一个版本就是仅做了前台校验,这个漏洞无意中被我发现了,因为每天都要登录OA,每次都要短信实在太麻烦了,我就尝试模拟了个表单请求,重写原登录系统表单提交的脚本,在所有的验证我都直接返回true。很激动的是,一次就成功了,后来也分享给我们同事了,大家都很开心。但随后不久,系统就升级了,后台验证,你们懂得。当然对当时的信息部同事来说,我就是一个坏人……

    3. 防止表单重复提交   安全等级★★★

    防止表单重复提交其实网上有很多解决方案,并且现在主流的前端框架都可以在页面上做按钮控制,不过做为一个程序员,你们懂得,这并没有什么卵用。个人还是建议采用实际的后台验证法处理。从网上爬文,看到的靠谱的解决方案如下。

    解决方案:token验证,请求页面时生成token并放在session中,提交表单到后台验证token,业务逻辑处理完之后,清除token。如果表单提交了一次,token就没了,再次提交就无法通过了。

    方案分析:此方法和验证码基本上一致,如果验证码在每次表单提交后都清除一次,也能达到这样的效果。

    其他建议:重要的表单页面提交后重定向,取消表单的autocomplete。

    4. 文件上传格式校验      安全等级★★★★

    黑客攻击网站还有一个常见的方式就是通过文件上传漏洞,比如网站上传图片的功能没有严格校验后缀名。黑客可以通过此功能上传一些脚本文件,上传成功后,通过请求这些脚本文件运行脚本中的功能达到攻击的目的。

    那么如果验证了上传文件的后缀名就可以吗?实际上并不是,举例说我们知道页面引入script标签时src写啥都行,比如http://www.baidu.com/123.jpg,也是可以的,攻击者只需要把一个script文件后缀名改为jpg即可通过后缀验证,后面一路畅通。所以这就提到了验证文件的真实格式。如何验证,网上一大堆…

    解决方案:设置php文件、jsp文件不可直接被访问(不知道php可以不,jsp放在WEB-INF即可),这样攻击者上传此类文件也无法执行;通过文件头信息严格验证文件格式,从上传功能开始防范。

    5. 熟悉使用框架或数据库版本情况   安全等级★★

    实际开发中,我们都使用一些开源框架,但这些框架也不是百分百完善的,比如webwork,struts2就经常爆出一些漏洞,这个需要开发者自行关注。

    解决方案:根据官方发布的方案进行版本升级;根据公开的漏洞执行方式编写拦截器。

    Struts2 s2-016 漏洞处理实例(项目结构不允许版本升级),拦截器,实际上官方的版本也是升级后过滤了一些参数。

    @Override
           public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain filterChain) throws IOException, ServletException {
                  HttpServletRequest req = (HttpServletRequest) request;
               HttpServletResponse res = (HttpServletResponse)response;
               //禁止页面被frame
               res.addHeader("x-frame-options","SAMEORIGIN"); 
                  Map parameterMap = req.getParameterMap();
            for (Iterator iterator = parameterMap.keySet().iterator(); iterator.hasNext();) {
                String key = (String) iterator.next();
                if ((key.contains("redirect:")) || (key.contains("redirectAction:")) || (key.contains("action:"))) {
                 res.sendError(HttpServletResponse.SC_FORBIDDEN, "forbidden");
                 System.out.println("----------非法操作-----------");
                    return;
                }
            }
            filterChain.doFilter(request, response);
           }


    6. 严禁在生产环境下使用缺省密码   安全等级★★

    很多时候一些小网站,新人练手的网站(往往价格很便宜),在开发的过程中都要求很快,往往这些网站问题还是蛮多的。后台验证码处于关闭状态、账号密码常用admin/admin组合,看似方便了操作,实际是危险重重。甚至有时候,数据库链接密码都是root/空,这个危害大家都知道。由于没有验证码,用户密码又使用的缺省的,黑客爆破的概率异常的高,一旦获取了后台管理权限,剩下的就交给你了。

    解决方案:通过配置测试模式和生产模式控制验证码验证,管理员账户必须使用非缺省加密处理,必要时使用物理验证。

    7. 服务器端口尽可能少开      安全等级★★★

    六月份一个客户的服务器被挂马了,服务器一直是他们自行维护,只在项目更新时给我们开放远程。无意中发现服务器防火墙竟然是关闭状态~~~~我的天呐,是不是所有端口都处于开放状态呐~~~~你们以为这就是惊喜,惊喜还在后面呢,客户提供的MySQL数据库用户名明码是root root,个人认为这个才是惊喜。root/root和root/空是一样的效果。分析了一下,防火墙关闭了,3306也就开了,黑客发现3306开着,root/root能连接,通过windows漏洞提升root用户为系统用户,bingo,竟然可以登录这台服务器欸,简直棒棒哒。

    解决方案:防护墙打开,仅开放必要的端口如80,13389,设置远程登录IP白名单。再次强调不要用缺省账户。

    8. Options方法过滤        安全等级

    这个问题网上提到的都是很严重,但现在并没有发现多少案例,或许处理方案比较简单吧。

    解决方案:在web.xml添加配置

       

    <!-- 过滤不安全的请求方法 -->  
        <security-constraint>     
        <web-resource-collection>     
           <url-pattern>/*</url-pattern>     
           <http-method>PUT</http-method>     
        <http-method>DELETE</http-method>     
        <http-method>HEAD</http-method>     
        <http-method>OPTIONS</http-method>     
        <http-method>TRACE</http-method>
        </web-resource-collection>     
           <auth-constraint>     
           </auth-constraint>     
        </security-constraint>     
        <login-config>     
            <auth-method>BASIC</auth-method>     
        </login-config>


    9. XSS攻击、CSRF攻击    安全等级

    XSSS攻击处理方案一般来说也是通过拦截器过滤请求参数,都是常规的处理方案。

    package com.interceptor;
     
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletRequestWrapper;
     
    /**
     * <p>
     *  类说明
     * </p>
     * @author shy
     * @date 2016-4-21 下午03:34:26
     * @vesion $Revision$ $Date$ 
     */
     
    public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper {
           HttpServletRequest orgRequest = null;  
             
        public XssHttpServletRequestWrapper(HttpServletRequest request) {  
            super(request);  
            orgRequest = request;  
        }  
      
        /** 
        * 覆盖getParameter方法,将参数名和参数值都做xss过滤。<br/> 
        * 如果需要获得原始的值,则通过super.getParameterValues(name)来获取<br/> 
        * getParameterNames,getParameterValues和getParameterMap也可能需要覆盖 
        */  
        @Override  
        public String getParameter(String name) {  
            String value = super.getParameter(xssEncode(name));  
            if (value != null) {  
                value = xssEncode(value);  
            }  
            return value;  
        }  
      
        /** 
        * 覆盖getHeader方法,将参数名和参数值都做xss过滤。<br/> 
        * 如果需要获得原始的值,则通过super.getHeaders(name)来获取<br/> 
        * getHeaderNames 也可能需要覆盖 
        */  
        @Override  
        public String getHeader(String name) {  
      
            String value = super.getHeader(xssEncode(name));  
            if (value != null) {  
                value = xssEncode(value);  
            }  
            return value;  
        }  
      
        /** 
        * 将容易引起xss漏洞的半角字符直接替换成全角字符 
        * 
        * @param s 
        * @return 
        */  
        private static String xssEncode(String s) {  
            if (s == null || "".equals(s)) {  
                return s;  
            }  
            StringBuilder sb = new StringBuilder(s.length() + 16);  
            for (int i = 0; i < s.length(); i++) {  
                char c = s.charAt(i);  
                switch (c) {  
                case '>':  
                    sb.append('>');//全角大于号  
                    break;  
                case '<':  
                    sb.append('<');//全角小于号  
                    break;  
                case '\'':  
                    sb.append('‘');//全角单引号  
                    break;  
                case '\"':  
                    sb.append('“');//全角双引号  
                    break;  
                case '&':  
                    sb.append('&');//全角  
                    break;  
                case '\\':  
                    sb.append('\');//全角斜线  
                    break;  
                case '#':  
                    sb.append('#');//全角井号  
                    break;  
                default:  
                    sb.append(c);  
                    break;  
                }  
            }  
            return sb.toString();  
        }  
      
        
        /** 
        * 获取最原始的request 
        * 
        * @return 
        */  
        public HttpServletRequest getOrgRequest() {  
            return orgRequest;  
        }  
      
        /** 
        * 获取最原始的request的静态方法 
        * 
        * @return 
        */  
        public static HttpServletRequest getOrgRequest(HttpServletRequest req) {  
            if (req instanceof XssHttpServletRequestWrapper) {  
                return ((XssHttpServletRequestWrapper) req).getOrgRequest();  
            }  
      
            return req;  
        }  
    }

    CSRF攻击(这个还在学习中)

    解决方案:从网上爬文看到的基本上是一致的,校验Referer,添加请求token验证,个人觉得此漏洞在大型系统中比较重视,小网站就呵呵了。

    10. frame引入控制      安全等级

    这个不知道为什么会被列入网站安全问题中,一个客户网站找了第三方安全检测公司检测网站有这个漏洞,所以就不得不处理。网上抄来的。

    Java代码(拦截器中使用):

    response.addHeader("x-frame-options","SAMEORIGIN");

    Nginx配置:

    add_header X-Frame-Options SAMEORIGIN

    Apache配置:

    Header always append X-Frame-Options SAMEORIGIN

    为毛没有tomcat的配置方式呢???




    相关资料:

    网站10大常见安全漏洞及解决方案


    展开全文
  • 众所周知,黑客入侵、网络攻击以及其他数字化安全漏洞从来都有百害而无一利。一个行业的烦恼可能是另一个行业的噩梦——如果你读过 Veracode 的《软件安全报告声明,卷6》,就会知道大多数安全漏洞在某些特定行业...
  • 什么是安全漏洞? 漏洞是在硬件、软件、协议的具体实现或系统安全策略上存在的缺陷,从而可以使***者能够在未授权的情况下访问或破坏系统。具体举例来说,比如在Intel Pentium芯片中存在的逻辑错误,在Sendmail早期...
  • web常见安全漏洞

    万次阅读 2018-09-08 10:07:40
    随着Web2.0、网络社交等一系列新型的互联网产品的诞生,基于Web环境的互联网应用越来越广泛,企业信息化的过程中,越来越多的应用都架设在Web平台上。...黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞...
  • 跨站脚本(XSS)漏洞 对参数做 html 转义过滤,要过滤的字符包括:单引号、双引号、大于号、小于号,& 符号,防止脚本执行。 在变量输出时进行 HTML ENCODE 处理 CSRF 漏洞 CSRF漏洞修复方案主要...
  • 1.6.2 安全漏洞披露方式  针对漏洞的公开披露策略与道德准则,在安全社区中曾爆发无数次的辩论,归纳起来,主要有如下四种主要的安全漏洞披露方式。 (1) 完全公开披露  发现漏洞后直接向公众完全公开安全漏洞...
  • 移动客户端安全漏洞等级划分

    千次阅读 2018-10-28 15:47:07
    移动客户端安全漏洞等级划分 移动客户端安全漏洞等级划分 我们将漏洞危害程度分为:严重、高危、中危、低危、无危险五个等级。其中定义移动客户端安全漏洞为以Flyme为核心的移动客户端安全漏洞。包括Flyme系统、...
  • 典型的安全漏洞生命周期

    千次阅读 2018-08-08 15:22:04
    1)安全漏洞研究与挖掘 由高技术水平的黑客与渗透测试师开展,主要利用源代码审核(白盒测试)、逆向工程(灰盒测试)、Fuzz测试(黑盒测试)等方法,挖掘出目标系统中存在的可被利用的安全漏洞 2)渗透代码开发与...
  • 关于rabbitmq安全漏洞的问题

    千次阅读 2018-01-08 14:12:53
    而最近呢,我们收到了一份关于安全漏洞扫描的文档,说我们的rabbitmq存在着一些安全漏洞问题,既然是有问题,自然是需要整改的,但是看完文档以后,发现这种安全漏洞问题似乎并不是很好解决。 文档中指出的问题主要...
  • Android手机App安全漏洞整理

    千次阅读 2019-06-12 16:36:39
    APP安全漏洞整理 1.源码安全漏洞 1.1 代码混淆漏洞 当前APK文件的安全性是非常令人堪忧的。APK运行环境依赖的文件/文件夹 res、DEX、主配文件Lib 只有简单的加密或者甚至没有任何加密。诸如apktool这类工具可轻易...
  • Redis安全漏洞影响及加固方法

    千次阅读 2018-10-12 17:04:38
    Redis安全漏洞影响及加固方法 Redis安全漏洞影响: 1、 Redis因配置不当可以未授权访问,很容易被攻击者恶意利用。如果Redis以root身份运行,黑客可以给root账户写入SSH公钥文件,直接通过SSH登录、控制服务器,引发...
  •  在渗透测试流程中,核心内容是找出目标系统存在的安全漏洞,并实施渗透攻击,从而进入到目标系统中。而这一过程最主要的底层基础是目标系统中存在的安全漏洞(Vulnerability)。 1.6.1 安全漏洞生命周期  安全...
  • Android WebView 安全漏洞解决方案

    千次阅读 2016-10-13 13:54:25
    Android WebView 安全漏洞最近发现公司的应用的WebView存在安全漏洞,找到了一些解决方案和大家一起分享一下,有什么理解不对的地方请多多指教。平时比较懒惰,有写博客的想法,但是懒动手,今天下了狠心想写写东西...
  • 一般来说,版本功能测试完成,对应的用例也实现了自动化,性能、兼容、稳定性测试也完成了以后,我们就需要考虑到系统的安全问题,特别是涉及到交易、支付、用户账户信息的模块,安全漏洞会带来极高的风险。...
  • 高校安全漏洞管理流程:你必须知道的几个要素 | Web安全 2017-07-21 09:42 高校信息安全管理是当前高校信息化工作的重点和难点。经过十余年的发展,各高校都基本完成了信息化建设的“原始积累”,拥有了相当数量的...
  • WiFi安全漏洞KRACK深度解读

    千次阅读 2017-12-13 17:52:22
    前段时间爆出的WiFi安全漏洞KRACK,波及了全球的WLAN设备,无人幸免,也就是说wifi用户连接网络,不论是在公司,家里,还是咖啡馆,都有可能遭受攻击,问题时发现了一个,还有没有发现的,也许还更严重的问题,又该...
  • Web安全漏洞分类

    千次阅读 2012-10-15 13:54:24
    1.1 Web安全漏洞分类 Web安全漏洞可以分为两类:一类包括平台的安全漏洞,另一类是应用自身的安全漏洞。 1.1.1 Web平台的安全漏洞 Web平台自身的安全漏洞——许多Web应用程序共享的部分,例如Linux、Windows、...
1 2 3 4 5 ... 20
收藏数 213,894
精华内容 85,557
关键字:

安全漏洞