代码安全开发-培训大纲-v1.2.ppt

上传人:聆听****声音 文档编号:2458981 上传时间:2023-05-03 格式:PPT 页数:106 大小:3.19MB
下载 相关 举报
代码安全开发-培训大纲-v1.2.ppt_第1页
第1页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第2页
第2页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第3页
第3页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第4页
第4页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第5页
第5页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第6页
第6页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第7页
第7页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第8页
第8页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第9页
第9页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第10页
第10页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第11页
第11页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第12页
第12页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第13页
第13页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第14页
第14页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第15页
第15页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第16页
第16页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第17页
第17页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第18页
第18页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第19页
第19页 / 共106页
代码安全开发-培训大纲-v1.2.ppt_第20页
第20页 / 共106页
亲,该文档总共106页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

代码安全开发-培训大纲-v1.2.ppt

《代码安全开发-培训大纲-v1.2.ppt》由会员分享,可在线阅读,更多相关《代码安全开发-培训大纲-v1.2.ppt(106页珍藏版)》请在冰点文库上搜索。

代码安全开发-培训大纲-v1.2.ppt

代码安全开发培训,技术支撑部(信息与系统安全部)2014.5,安全意识培训,openssl案例struts2漏洞案例WindowsMS08-067案例android应用开发接口威胁teensy演示,openssl案例,漏洞介绍无需任何特权信息或身份验证,我们就可以从目标上偷来X.509证书的私钥、与密码、聊天工具的消息、电子邮件以及重要的商业文档和通信等数据用户名。

受影响版本OpenSSL1.0.1、1.0.1a、1.0.1b、1.0.1c、1.0.1d、1.0.1e、1.0.1f、Beta1ofOpenSSL1.0.2等版本在线检测地址http:

/possible.lv/tools/hb/,openssl案例,漏洞原因OpenSSL的某个模块存在一个BUG,当攻击者构造一个特殊的数据包,满足用户心跳包中无法提供足够多的数据会导致memcpy把SSLv3记录之后的数据直接输出,该漏洞导致攻击者可以远程读取存在漏洞版本的openssl服务器内存中长大64K的数据修复方案网站方面,管理员及时下载OpenSSL补丁,升级OpenSSL1.0.1g,通知用户在升级期间不要登录网站,openssl案例,他是某个存在漏洞的站点,这是演示漏洞攻击,他可以随机获取对方网站的某用户的数据信息,包含用户名,密码,电话,省份证号等等,Struts高危安全漏洞,struts漏洞一直以来都是非常引人瞩目,两方面原因:

用struts框架的应用一般都是比较大型的应用;struts漏洞一般都是高危漏洞。

下面列举struts自发布以来已知的漏洞:

关于Struts2高危安全漏洞,漏洞介绍近日有安全研究人员指出ApacheStruts2在漏洞公告S2-020里,在处理修复CVE-2014-0094漏洞修补方案中存在漏洞,导致补丁被完全绕过。

目前官方在github上做了对应修改。

这是OpenSSL之后又一严重漏洞,安全情况等级再次升级!

受影响版本ApacheGroupStruts2.x漏洞原因ApacheStrutsversions2.0.0-2.3.16版本的默认上传机制是基于CommonsFileUpload1.3版本的,该版本在实现上存在拒绝服务漏洞,附加的ParametersInterceptor允许访问class参数(该参数直接映射到getClass()方法),并允许控制ClassLoader。

struts2高危安全漏洞的影响,关于微软MS08-067漏洞,这个漏洞比较古老,杀伤力很大,但是在很多场景下还是普遍存在,应引起重视。

漏洞介绍该安全漏洞可能允许远程执行代码,如果受影响的系统收到了特制伪造的RPC请求。

在MicrosoftWindows2000、WindowsXP和WindowsServer2003系统,攻击者可以利用此漏洞无需通过认证运行任意代码。

受影响版本win2k,xpsp3,2003,2008,vista,win7beta漏洞原因攻击者发出恶意请求给RPC服务,导致缓冲区溢出。

攻击者可取得主机权限,关于微软MS08-067漏洞,android应用开发接口威胁,通过分析app程序【电信某系统】,可以找到其调用数据的接口,修改提交的参数可以找出敏感数据。

http:

/202.102.XX.XX/app/JSONLogin?

managerID=250006510,http:

/202.102.XX.XX/app/JSONLogin?

managerID=250006520,teensy,很多场景,黑客可以用伪装过的u盘,对指定目标进行攻击。

teensy就可以伪装成任意一种usb外接设备。

常见用途有:

1.直接获取系统响应的权限2.键盘记录器3.快速窃取文件,teensy,一小段代码就可以让teensy摇身一变成为一个键盘记录硬件。

teensy,通过将一个木马写入teensy,可以让系统自己动加载、运行。

作图为远程监听并执行系统命令的木马控制截图。

teensy,源代码:

【仅供参考】,安全编码原则,程序只实现你指定的功能永不要信任用户输入(来自用户终端的数据),对用户输入数据做有效性检查必须考虑意外情况并进行处理不要试图在发现错误之后继续执行尽可能使用安全函数进行编程小心、认真、细致地编程,安全策略条目分类,Discipline:

必须遵守的纪律,必须按照规范中的描述严格实施,绝对不能违反Policy:

必须遵循的策略,实现方法可以自行考虑,但不能违反策略的规定Guideline:

建议性的指南和规范,重要系统实施,其他系统逐步遵循实施,代码安全开发注意点,身份验证会话安全访问控制输入输出验证异常管理文件操作安全管理数据安全日志审计安全接口安全系统接口安全测试规范,身份验证,应用系统帐号管理安全要求主要包括保护帐号不被猜解和暴力攻击,提供对帐号用户身份的有效识别,帐号状态管理,帐号有效期管理等,应在程序设计时,严格控制各个安全点,强制用户必须满足其要求。

具体内容涉及以下要求:

帐号安全密码安全认证安全测试,身份验证,身份验证案例用户名admin密码agent,身份验证,身份验证案例用户名输入-1or89=90密码输入1,帐号安全,帐号名称系统管理员帐号名称禁止使用易猜解名称【Discipline】系统管理员帐号名称不使用常见管理员的帐号名称,如“admin”、“administrator”、“root”等,不使用管理员个人标识信息(如姓名拼音等)作为管理员帐号名称,避免被攻击者暴力猜解。

帐号安全,帐号身份帐号身份的安全有效管理【Policy】为对帐号进行有效管理,在帐号发生安全事件时能及时有效的定位责任人,密码找回等,要求系统提供对帐号的使用人员必要的身份信息管理功能,如:

有效证件,邮件,手机等,并对身份信息进行有效性验证。

系统通过加密存储、页面展现脱敏处理等多种手段提供对敏感身份信息的安全保护。

数据安全保护详见相关章节。

密码安全,设置密码通常起到认证用户身份、防止攻击者非授权访问的安全措施。

因此密码也通常被认为突破系统的第一道防线,系统禁止接收不满足安全标准的登录密码。

保障密码安全系统必须具备密码安全管理功能,需要满足以下要求:

密码长度Discipline1-2-1:

必须严格按照要求控制密码的长度管理员密码长度需在8位以上,普通用户密码需在6位以上。

帐号安全,帐号状态管理帐号身份状态的安全有效管理【Policy】系统具备帐号状态管理功能,帐号的状态包括:

在用,临时,暂停,关闭等,帐号的状态变更满足以下要求:

临时帐号设置有效期,到期自动关闭。

长期不用的帐号,三个月未登录,自动转换到暂停状态。

密码安全,密码复杂度密码的复杂度设置必须满足要求【Discipline】大写字母、小写字母、特殊字符、数字三种以上组合。

禁止使用连续性字符、数字,如1234abcd。

避免重复字符、数字,如11111、aaaaa等。

不要使用用户公开信息或个人隐私相关数据作为密码,如:

qq、身份证号码、昵称、电话号码、生日、姓名拼音、英文名、公司名等,避免被社会工程学攻击。

支持采用黑名单对常用统计型弱密码的过滤,如:

常见的统计型弱口令123321、qwerty、qweasd、qazwsx、1q2w3e4r等。

密码安全,密码存储密码的存储必须使用散列函数加salt【Discipline】必须采用不可逆加密算法(MD5、SHA-1等)加密存储,为防止彩虹表暴力破解,在对密码加密时增加明文复杂度,增加一个“salt”和对应帐号信息,具体如下:

MD5(Username+Password+salt)其中salt=abkdfang.(随机字符串)Salt保存在服务器端配置文件或数据库中,妥善保存,密码安全,密码生存周期必须严格限制密码的生存周期【Discipline】提供密码生存周期管理,满足以下要求:

管理员用户(root、Administrator等)3个月强制更换一次密码。

普通用户每次登录前确认当天离上次更新是否超过90天,如超过则不允许登入,如超过最后期限前3天自动提示离下次更新密码的最后期限还有多少天。

密码分发Guideline1-2-5:

加强密码的安全分发系统应提供对用户初始密码分发和用户密码重置的安全管理,避免可能的安全风险,应满足以下要求:

用户初始密码应由系统通过算法随机生成,禁止使用统一的初始密码。

初始密码的分发应由系统通过用户创建时登记的email或手机进行自动分发,减少人工环节。

用户使用初始密码首次登录系统时,系统应提醒或强制用户修改密码。

密码安全,密码分发加强密码的安全分发【Guideline】系统应提供对用户初始密码分发和用户密码重置的安全管理,避免可能的安全风险,应满足以下要求:

用户初始密码应由系统通过算法随机生成,禁止使用统一的初始密码,且密码强度要大,至少为8位。

初始密码的分发应由系统通过用户创建时登记的email或手机进行自动分发,减少人工环节。

用户使用初始密码首次登录系统时,系统应强制用户修改密码。

密码安全,密码修改必须严格限制密码修改的条件【Discipline】密码修改管理要求先验证用户原有密码才允许修改密码。

密码找回密码找回的安全有效手段【Discipline】系统必须采用安全的方式验证用户的身份并重置密码:

通过验证用户预留的密码找回问题和答案来验证身份。

通过用户预留的email验证身份,系统自动发送重置以后的密码或重置密码的URL。

通过向用户预留的手机号码发送短信动态码来验证身份,短信动态码长度不低于6位,且有效时间不超过5分钟,错误5次以上失效,避免被分布式暴力破解。

认证安全,认证方式管理高安全等级系统的认证方式【Discipline】高安全等级系统认证方式应不低于以下要求:

用户名+用户名+静态密码+动态密码(令牌卡、短信码),动态密码长度不低于6位,设定密码的有效时间不超过5分钟,防止动态码被攻击者采用词典或者穷尽的方式暴力攻击,请求间隔不少于60秒等。

静态密码+证书认证。

二次鉴权管理高安全等级重要操作必须经过系统二次鉴权【Discipline】对高价值交易操作和进入保护区用户进行重新认证,如:

修改用户密码操作、涉及资金操作等。

认证安全,图形验证码管理图形验证码的安全使用【Guideline】验证码防自动识别:

认证登录框具备图形验证码功能,且图形验证码满足以下要求:

能抵抗自动识别,但不影响用户的正常识别,实现长度至少四位的随机字符串,且使用扭曲、噪点干扰、大小变换、位置变换等防自动识别的一种或者多种方法,或者增加简单的逻辑判断,如:

1+一=?

等。

验证码保护和更新:

采用session方式在服务器端保存验证码值,每次核对验证码时候先检查是否为空,核对验证码后先将session中验证码值清空,然后再做其他数据合法性判断。

可能存在的风险,session中的验证码值如不在每次核对以后自动清空,攻击者可以通过不触发验证码更新程序的方式采用第一次人工识别的验证码反复提交绕过验证码;cookie方式保存验证码值,攻击者可以通过解密识别cookie中的验证码值或者直接伪造cookie值来绕过验证码。

认证安全,认证敏感信息通信安全敏感信息使用安全通道传输【Policy】认证过程中,涉及密码和用户名的通信,需使用加密通道来进行身份认证,如:

使用https协议来传递认证信息。

认证安全,认证失败处理认证失败时相应的安全处理方法【Discipline】登录认证失败处理必须满足以下要求:

登录界面认证失败时,认证失败的回显信息不能单独显示“帐户错误”或“密码错误”等精确的提示信息,应由系统生成统一的错误页面信息,避免攻击者通过错误信息来猜解帐号是否存在。

具备连续认证失败后帐号锁定功能,帐号可以由系统管理员解锁或者系统在一定时间内自动解锁,防止帐号密码被手动暴力猜测,但必须考虑配合图形验证码或者动态密码等辅助手段,防止攻击者利用自动工具尝试暴力认证登录,导致正常用户大批量锁定的DOS攻击行为。

对高安全等级系统可以考虑实现:

多次认证失败后,系统应通过短信、邮件等方式提示帐户本人其帐户安全问题,督促尽快修改密码或设置安全密码、密码保护等。

为保护帐户免受暴力破解的影响,针对多次认证失败的情况,系统可以主动拒绝攻击地址的访问。

认证安全,系统登录安全高安全等级系统必须使用安全访问策略【Discipline】高安全等级系统应支持应用级的登录安全访问控制策略,满足以下要求:

对系统后台管理员登录页面,应限制访问的IP地址范围。

对特殊权限管理员(如码号管理员),应限制登录的终端IP地址范围或MAC。

测试,爆破账号,测试,爆破账号,会话安全,会话在用户访问系统的整个过程中起到识别用户、保持与服务器的连接的功能。

会话的安全涉及到用户的隐私信息等问题,在开发过程中,需多多注意。

包括以下几点:

会话的安全初始化会话的安全终止会话的安全使用域会话中用户标识数据的安全保护测试,会话安全,会话创建会话的安全初始化【Policy】创建的会话凭证应满足随机性和长度要求,避免被攻击者猜解。

注释:

这里的会话凭证就是sessionid,如Cookie:

PHPSESSID=dh8drj7hkmttr81igng4g5pqo7;在同一用户的登录过程中,当用户本次认证成功后,应为此用户创建新的会话并释放原有会话,一旦发现同一帐户多点登录时提示“当前用户存在多点登录情况,如非本人操作请尽快修改用户密码或使用登录保护”。

注释:

这里可以加入心跳包检测,并设置锁定时间。

从安全级别较低的模块跳转到安全级别较高的模块时,应用必须重写Session信息。

每一个Cookie都应该带上HttpOnly的标签,防止本地脚本读取cookie信息,也是为了应对xss攻击。

会话安全,会话终止会话的安全终止【Policy】缩短会话寿命可以降低会话劫持和重放攻击的风险,会话寿命越短,攻击者捕获会话凭证并利用它访问应用的时间越有限。

会话的生存期必须控制在一定的时间范围内,如1小时、1天,最高不得超过1天。

超过生存期的使用时间后,必须将会话终止,并强制用户重新获取会话。

在用户退出系统时,服务器端及时注销会话数据。

在B/S结构的应用程序中,当处于登录状态的用户直接关闭浏览器时,提示用户执行安全登出或自行为用户完成登出过程,确保此次会话终止。

如果在一定时间的范围内,用户未对系统进行任何操作,系统需终止此会话,并强制用户退出系统。

会话安全,会话权限会话的安全使用域【Guideline】设置Cookie的域,强制要求Domain和Path的吻合。

在一个大型Web站点中,往往有多个应用,生存在不同的子域名或路径下。

这些应用之间由于共享同一个域名,所以往往可能会彼此有操作对方应用Cookie的能力。

这种情况下,用户Cookie的Domain和Path属性限制在合理的区间,用户只能访问此domain+path下的web页面。

会话安全,会话安全防御针对会话安全的攻击手段非常多,很多常规的攻击方式在特定的环境下,都可以针对会话进行攻击,从而达到非法获取权限的目的。

下面几点是在会话安全中需要注意的。

会话中用户标识数据的安全保护【Policy】用户登录成功以后生成的会话数据应存储在服务器端,并确保会话数据不被非法访问。

会话凭证不得包含明文的用户信息(如SessionID=user.admin8829hdakkqwekkq)。

会话凭证加密不得单独使用MD5或sha等散列算法,如在明文中加入salt值再加密,或者进行二次散列,防止彩虹表破解。

访问控制,访问控制一词在安全领域出现的频率非常高,访问控制其实就是权限的控制,对于权限的合理分配,一直是安全设计中的核心问题。

在开发过程中,需注意以下几点:

角色安全设置系统运行环境帐号权限管理资源访问控制不安全的直接对象引用,访问控制,角色安全设置角色的安全设定【Guideline】应用系统应预先生成不同的角色,不同的角色拥有不同的权限,不同的权限可以赋予同一个帐号。

设计角色时,设计者应根据系统特定,尽可能细化各种权限。

(如管理员修改数据表,可以设计成特定的权限修改特定的数据表)根据业务发展需要,赋予角色相应的生命周期。

访问控制,系统运行环境帐号权限管理系统运行环境的安全设置【Discipline】应用软件启动权限最小化:

避免因应用缺陷导致攻击者直接获得管理权限,系统使用的系统帐号(运行环境)应该仅有运行该应用所必需的最小权限,禁止使用root、administrator、sa或其他特权帐号来运行应用程序。

数据库连接帐号权限最小化:

避免攻击者通过数据库连接帐号直接获得管理权限,系统应使用必需最小权限的数据库连接帐户访问数据库,禁止使用sa、system或其他特权数据库帐号。

数据库帐号的安全划分:

不同安全等级的数据表帐号分离,如:

实例数据表和配置数据表的数据库帐号分离,普通数据表和敏感数据表(重要数据、密钥数据等)帐号分离。

访问控制,资源访问控制案例案例:

直接访问后台,访问控制,资源访问控制案例案例:

直接访问后台,访问控制,资源访问控制案例案例:

访问敏感文件http:

/132.228.XX.XX:

7001/servlet/downloadservlet?

filename=%E8%AE%A1%E8%B4%B9(BOSS)%E7%BD%91%E7%AE%A1%E6%93%8D%E4%BD%9C%E6%89%8B%E5%86%8C.chm&pathname=/././././././././././etc/passwd%00.chm,访问控制,资源访问控制案例案例:

越权访问,访问控制,资源访问控制资源访问控制的安全设定【Guideline】限制普通用户对系统级资源的访问:

系统资源包括文件、文件夹、注册表、数据库、日志,不同的用户和角色只允许访问特定的资源。

敏感功能IP地址控制:

敏感功能(如后台管理)应采用黑名单或者白名单对访问的来源IP地址进行限制,防止非法IP接入和地址欺骗。

服务器端实现访问控制:

应在服务器端实现对系统内受限资源的访问控制,禁止仅在客户端上实现。

服务器资源控制:

在服务器端限制客户端最大的请求数,避免用户无限制的访问或恶意耗尽系统资源。

URL访问控制:

如果这个URL不是公开的,那么必须限制能够访问他的授权用户:

加强基于用户或角色的访问控制;完全禁止访问未被授权的页面类型(如配置文件、日志文件、源文件等)。

验证构架:

在每一个层次都使用简单肯定的模型;确保每一层都有一个访问机制。

验证实现:

不要使用自动化的分析工具;确保每个URL都被外部过滤器或其他机制保护;确保服务器的配置不允许对非授权页面的访问。

访问控制,不安全的直接对象引用引用对象的安全设定【Policy】“不安全直接对象引用”是指一个授权用户,通过更改访问时的一个参数,从而访问到其原本未得到授权的对象。

Web应用往往在认证成功生成Web页面时会默认服务器返回的数据使用用户的真实参数或者使用文件路径来访问服务器文件(如:

任意文件下载漏洞),但并不会在后续对所有的目标对象的访问检查用户权限,从而造成漏洞,这种漏洞可以损害参数所引用的所有数据,危害极大,必须严格杜绝。

客户参数不安全引用问题举例:

客户在查询自己的手机详单时,发现浏览器发往服务器的参数是18901589999,即?

acct=18901589999,他可以直接更改参数为18901588888,即?

acct=18901588888,从而非授权获取了18901588888客户详单信息。

安全措施:

对于所有敏感功能模块,系统在接收来自授权用户客户端的参数时,必须检测此参数是否在该用户的授权范围内,或者从服务器端提取参数,防止参数在客户端篡改。

服务器端文件不安全引用问题举例:

download.jsp?

file=downloadfile,构造参数file=/./././././././././etc/passwd,访问控制设置不当的情况下,导致访问者直接获取/etc/passwd。

安全措施:

在根据客户端的输入访问服务器端的文件时,应防止通过真实的文件名来访问文件,应使用索引值来映射实际的文件路径。

如确实需要在参数中出现文件名,则应对文件名进行白名单检查。

禁止在参数中出现./、.等特殊字串及其变形。

输入输出验证,通常黑客攻击系统,就是通过输入某些特殊的数据或者字符串,来检验系统是否安全。

如果系统没有做好输入和输出的验证和防御,很可能造成恶意的输入直接攻击系统、不应该让客户看到的信息暴露在外。

因此在开发过程中,针对输入和输出的数据需特别小心。

请注意以下几点:

输入验证输出安全,输入输出验证,输入验证对输入数据的安全过滤和验证【Policy】正确的输入验证是防御目前应用程序攻击的最有效方法之一。

验证策略满足以下要求:

对所有的输入进行安全验证:

包括来自用户、服务、文件、和数据库的输入;对web系统验证http请求的全部字段,包括get、post、cookie、header等;除了验证数据的内容外,还需要限定数据的大小和长度。

采用集中验证方法:

通过使用共享库中的公共验证模块或者编写统一的数据验证接口,集中处理输入数据。

采用严格的验证方法:

验证数据类型是否匹配;验证数据长度是否在预期长度范围内;验证数值类型是否在预期大小边界内;验证数据是否包含特殊字符(如、”、(、)、&、#、|、-等);使用白名单验证方法。

验证过程必须在服务端执行,不要依赖客户端验证,防止验证功能被客户端绕过。

输入输出验证,输出安全目录遍历案例,输入输出验证,输出安全敏感信息泄露通过知道用户在系统中的手机号码,就可以通过此页面查询到对于的用户名,可以帮助忘记用户名的用户进行利用手机号码查询。

输入输出验证,输出安全对输出数据的安全过滤和验证【Policy】输出环节主要的安全威胁:

根据输出目标的不同,应对输出数据进行相应的格式化处理;WEB应用中,系统的输出需进行HTML编码,尤其客户端提交的输入不能直接传递到客户端。

与业务无关的信息禁止输出用户界面。

输出不能包含任何隐私信息,如用户信息、部门信息、非公共邮箱等。

应用系统页面中不得包含任何关于系统的版本的信息和制作团队的信息,如“PowerBy*Ver1.1”,页面代码中也不得包含版本信息或制作团队的标签记号,如特殊的tag。

应用系统不得显示当前应用所在服务器状态或系统架构的信息,如phpinfo.php页面所提供的信息,防止攻击者通过探针脚本获取当前架构的信息进而获取系统的架构漏洞或设计缺陷。

应用中不得包含任何功能测试页面,防止攻击者利用测试页面深入了解系统的运行原理、挖掘应用漏洞。

应用中不得包含任何调试页面,防止攻击者通过调试信息获取应用运行的细节信息,从而挖掘出漏洞信息和管理员工作习惯。

应用管理后台路径混淆处理,避免使用默认路径,避免使用常用的路径名称,如admin,manager,administrator等,防止被猜解。

应用服务器应关闭目录遍历功能,防止攻击者非法获取应用文件。

对输出数据的安全过滤和验证,注入防御XSS攻击防御CSRF攻击防御,注入防御,SQL注入案例:

注入防御,简单来说,注入往往是应用程序缺少对输入进行安全性检查所引起的,攻击者把一些包含指令的数据发送给解释器,解释器会把收到的数据转换成指令执行,注入漏洞十分普遍,通常能在SQL查询、LDAP查询、Xpath查询、OS命令、程序参数等中出现。

注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。

注入漏洞有时甚至能导致完全接管主机。

包含以下几点:

SQL注入防御XML注入防御HTTP头注入防御命令注入防御,SQL注入防御,SQL注入的定义:

SQL命令就是前端应用程序和后端数据库之间的接口。

攻击者可利用应用程序根据提交的数据动态生成SQL命令的特性,在URL、表单域,或者其他的输入域中输入自己的SQL命令,改变SQL命令的操作,将被修改的SQL命令注入到后端数据库引擎执行。

SQL注入防御,SQL注入的危害:

数据库信息泄漏:

数据库中存放的用户的隐私信息的泄露。

网页篡改:

通过操作数据库对特定网页进行篡改。

网站被挂马,传播恶意软件:

修改数据库一些字段的值,嵌入网马链接,进行挂马攻击。

数据库被恶意操作:

数据库服务器被攻击,数据库的系统管理员帐户被窜改。

服务器被远程控制,被

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2