常见安全漏洞和解决方案.docx

常见安全漏洞和解决方案.docx

《常见安全漏洞和解决方案.docx》由会员分享，可在线阅读，更多相关《常见安全漏洞和解决方案.docx（13页珍藏版）》请在冰豆网上搜索。

常见安全漏洞和解决方案

1.1身份认证安全

1.1.1弱密码

●密码长度６个字符以上

●密码字符必须包含大写字母、小写字母和数字，并进行密码复杂度检查

●强制定期更换密码

1.1.2密码存储安全

密码存储必须使用单向加密

单纯的md５，ｓｈa１容易被破解，需要添加随机的盐值ｓalt

涉及支付及财产安全的需要更高的安全措施，单纯的密码加密已经不能解决问题。

可以考虑手机验证码、数字证书、指纹验证。

1.1.3密码传输安全

1.1.3.1密码前端加密

用户名、密码传输过程对称加密,可以使用密钥对的对称加密,前端使用公钥加密，后端使用私钥解密。

前端加密示例

引入脚本,rsa加密工具和mｄ5加密工具

。

。

。

〈scrｉptsrｃ=”＄{ｒesoｕｒcepath｝/jsencryｐt/biｎ／jsencrypt.min。

js＂　tｙpe=”tｅxt／jaｖasｃript"〉〈/sｃｒipt>

〈ｓｃｒipｔｓrc="$｛ｒesourcepaｔｈ}/jsｈash-2.2/md5－min。

ｊs”ﻩtｙpe="teｘt/jａvascｒiｐt”〉<／ｓcrｉpt>

．.。

前端加密脚本，省略了提交步骤

…

＜sｃrｉpt>

．．.

ﻩ//rsa加密，

ﻩvaｒpublicKey=　＇＄｛rsａＰubｌicＫey｝’;

ﻩﻩﻩｖarｅｎcryｐｔ=nｅwJＳEnｃrypt（）;

ﻩﻩﻩeｎcrｙpt。

sｅｔＰublicKey（publicKey）;

ﻩﻩﻩ／/加密

ﻩﻩｖarusername=encrｙpt.encｒypｔ（＄（＇input［nａｍｅ=　username]'）.val（））;

ｖaｒpasｓword=encrｙpt。

encrypt（$（'ｉnput[name=paｓsword]’）。

vaｌ（））；

..。

…

注意：

前端密码加密如果还用了md5加密的,先md5加密再rsa加密。

后端解密,省略了其他验证步骤

ＳhirｏUsｅrＳerviceImpl。

ｊａvａ

…

ﻩpublic　ＳhiroUｓergetUser（Stｒingｎamｅ，Ｉnteger　ｕseｒTｙpe，IntegerlogｉｎType）　｛

ﻩﻩnaｍe＝RＳAUtils。

deｃryptBase６4（ｎame）；

…

｝

…

ｐubｌic　ｂｏolean　doValｉdUｓer（ShiroＵsｅｒshｉroUser,Stringpasswoｒｄ）　｛

ﻩpassｗoｒd=RSＡUtils.decrypｔBaｓe64（ｐａsswｏｒd）;

…

｝

1.1.3.2启用hｔtps协议

登录页面、支付页面等高危页面强制httｐs协议访问。

前端加密和https可以结合使用

1.2SQＬ注入

1.2.1描述

SQL注入攻击是黑客对数据库进行攻击的常用手段之一.随着Ｂ/S模式应用开发的发展,使用这种模式编写应用程序的程序员也越来越多。

但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。

用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的ＳＱＬＩnｊｅｃtion,即SQＬ注入。

1.2.2解决办法

1.养成编程习惯,检查用户输入,最大限度的限制用户输入字符集合.

2.不要把没有检查的用户输入直接拼接到ＳQL语句中，断绝SQＬ注入的注入点。

●ＳＱL中动态参数全部使用占位符方式传参数.

正确

。

.．

Ｌiｓt〈Ｏbjecｔ>　paｒamｓ=newAｒrａyLｉst〈Object＞（）;

Stｒingsql　＝　”ｓelect*ｆrｏmuｓeｒ　wherｅloｇin_namelike?

";

paraｍs．adｄ（ｕsernaｍｅ）；

。

．。

正确

..。

Mapparａｍs=　ｎewHashMap＜Sｔring,Ｏbｊect＞（）；

Sｔriｎgｓqｌ　="selｅct*　from　uｓerｗherelogiｎ_namｅlike:

logｉｎnaｍe"；

params.put（”useｒｎame”，usｅrｎａme）；

..．

错误

　。

.。

Ｓtｒiｎgsｑl＝　”ｓelect＊frｏｍusｅr　wｈerelｏｇin_ｎａmｅ＝'"＋　ｕseｒnaｍe+＂'"；

.。

.

●如果不能使用占位符的地方一定要检查SＱL中的特殊符号和关键字,或者启用用户输入白名单，只有列表包含的输入才拼接到ＳＱL中，其他的输入不可以。

Sｔringsql=　"seｌeｃt*from”＋SqlＴoｏｌs．ｆｉｌtｅｒInjectiｏn（ｔａblename）；

1.2.3应急解决方案

ngｉnx过滤规则naxsi模块

axsi_nbs．ruｌes

##Ｅnableｓ　learnｉngmoｄe　

#LearningMｏde；

ＳｅcRulesEｎabled；

#SecＲｕｌesDisabｌｅd；

DeniedＵrl”／５0x。

hｔｍｌ＂；

＃＃cｈeck　rules

ＣhecｋRulｅ　"＄SQL　>＝８＂　ＢLOCK;

ChecｋRule　”＄RFI〉=8＂BLOCK；

ChecｋＲule”＄TＲAＶEＲSＡL〉=4"BLOCK；

ＣｈｅｃkRｕle　”$EＶＡDE〉=　4"BLOCK;

ＣheckRule＂＄XSＳ　〉=　8"　ＢLOCK；

标红部分就是SQL注入过滤规则启用级别.

基础滤规则已经级别定义省略，可自己定义。

1.3跨站点脚本攻击（ＸSS）

1.3.1描述

ＸＳS（Ｃｒoss　SｉｔeSｃriptiｎｇ，跨站脚本漏洞），是Ｗeb应用程序在将数据输出到网页的时候存在问题,导致攻击者可以将构造的恶意数据显示在页面的漏洞。

1.3.2解决办法

1养成编程习惯,检查用户输入，最大限度的限制用户输入字符集合。

2不要把用户输入直接显示到页面，不要相信用户的输入。

●编码把用户输入编码后输出

正确

。

。

。

ｏｕｔvaｌｕｅ＝"$｛用户输入}"〉〈／c：

ｏut〉

..。

错误

.。

.

${用户输入｝”

..．

●富文本编辑器和直接显示编辑的HＴML，项目总尽量不要开放，如果开放就要严格检查XＳS敏感HTML片段,并且严格控制用户权限,做好IP限制这些安全措施.

注意：

所有XSＳ过滤器如果要保证过滤后ＨTML能正常浏览,都只能过滤部分已知的ＸSS攻击，开发HTMＬ编辑始终存在风险和隐患。

1.3.3应急解决方案

web过滤器

weｂ。

ｘml

..。

ﻩ

—-跨站点脚本过滤

参数：

excludeＵｒl排除链接,不参与过滤的链接，支持anｔ风格的通配符

参数:

ｓtriｃt是否严格模式,严格模式基本只要有大于小于都会拦截，宽松模式只拦截scｒipt这些已知的攻击脚本

ﻩ-－＞

＜fiｌter＞

ﻩ〈ｆiｌｔer—naｍe〉IllegａｌCharａｃterFilter〈／filtｅｒ—name＞

ﻩﻩ

ﻩﻩcom。

wondersgrｏｕｐ.ｗssｉp。

ｆｒamewｏrk.ｗeb.fiｌter。

ＩllegaｌＣｈaracterFiltｅr

ﻩ〈/filｔer-clasｓ＞

〈init－parａm〉

ﻩ〈ｐａram—name>ｅxcludeUｒl

ﻩﻩ〈paｒam—value>/resource/＊,／*＊/*。

imａｇes＜/pａram－vaｌuｅ＞

ﻩ＜／init—paｒam>

<ｉnit—ｐａrａm〉

ﻩﻩﻩ〈paｒaｍ—nａmｅ〉ｓtricｔ＜/pａrａｍ-namｅ>

ﻩ〈pａram-vａlue＞fａlsｅ

ﻩ＜/init－ｐarａm〉

ﻩ

ﻩ

ﻩ＜fiｌｔer－namｅ>ＩｌｌeｇａlChａｒactｅrFｉlteｒ

＜uｒl-paｔteｒn〉/＊〈／ｕrl-pａｔｔern〉

ﻩ＜/ｆilter—maｐpinｇ>

．..

注意：

这种方式效率低下,对应大数据提交响应很慢，不推荐。

　　　　HＴML编辑器会被这个过滤器拦截，需要特殊处理。

nginx过滤规则naxsi模块

ａｘsi＿nbs．rules

＃＃Ｅnabｌｅｓlearningｍodｅ

＃LeaｒｎingMode；

SecRulesEnａblｅd;

＃SecRulｅsDisaｂled；

DeniedUrl”／50x。

hｔｍｌ”；

#＃　check　rules

CheckRulｅ”$SQL＞=8＂BLＯCK;

CheckＲule”$RFI　〉＝　8＂BLＯCK；

ChｅｃｋRulｅ”＄TＲAVERSAL　〉=4”　BLOCK；

CheckRuｌe　”＄EVADE>＝　4＂　ＢLOＣK；

ＣheckRｕｌｅ"$XＳS>＝8"BLOＣK；

标红部分就是XSS注入过滤规则启用级别.

基础滤规则已经级别定义省略,可自己定义。

默认的规则８级只要带＜>符号的通通拦截。

1.4跨站请求伪造（ＣSRＦ）

1.4.1描述

ＣＳRF（CrossSiteＲequeｓｔForgery,跨站域请求伪造）是一种网络的攻击方式，该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作，有很大的危害性。

1.4.2解决办法

1.验证　HＴTＰRefeｒer字段

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

服务器生成tokeｎ，输入界面获取tｏｋen，提交是带上toｋen,服务器验证ｔokｅｎ

注意！

关键操作,还需要加入用户交互操作

比如付款,转账这样的操作一定要用户再次输入密码（或者独立的支付密码）,在加上可靠的图片验证码或者手机验证码。

3.在HＴTP头中自定义属性并验证

1.4.3应急解决方案

weｂ过滤器

wｅｂ．xｍl

。

..

—－　CSＲF（CｒoｓsSiteRequesｔＦorｇeｒy，跨站域请求伪造）过滤

参数：

eｘcluｄeＵrl排除链接，不参与过滤的链接,支持ant风格的通配符

参数：

ｒeｆerｅrＵrl　允许的refｅrｅr，支持anｔ风格的通配符

-->

ﻩ〈filteｒ>

＜filter-clasｓ＞

ﻩｃｏｍ.wｏnderｓｇroup。

wssiｐ.frａmeworｋ．web。

filter.ＣsrfFiｌter

ﻩﻩ

ﻩ＜param-namｅ＞ｅxｃludeUrｌ

ﻩ

ﻩﻩ〈/ｉｎit－paｒａｍ〉

〈ｉnit—param〉

reｆerｅｒUrl<／ｐaraｍ-ｎame〉

ﻩ＜paｒam—ｖalue〉ｈtｔp:

//127.0.０．1：

9080／＊*/＊，https:

／／１27。

0。

0。

1:

４44３/＊＊／*〈／param—vａlｕe〉

ﻩﻩ＜／inｉt-ｐａｒaｍ〉

〈filteｒ—ｍapping〉

ﻩﻩ<ｆilter－naｍe〉CｓｒｆＦilter

ﻩ＜uｒl-pａｔｔerｎ＞/＊<／url—paｔｔeｒn>

ﻩ

．..

注意：

修改允许的refeｒer白名单rｅferｅrUｒｌ。

1.5X-Fｒame－Opｔiｏｎｓ未配置

1.5.1解决办法

1.5.1.1apａche

htｔｐ.conf

。

。

。

＃ｓetX-Ｆrａmｅ-Ｏpｔions

HeadeｒalwａyｓaｐｐendX—Frame－OptionsSAMEORIGIＮ

。

..

注意：

apaｃｈe２４默认就配置了

1.5.1.2nginx

nginx。

ｃonf

。

。

.

add＿header　X－Fｒame-Ｏｐtｉons　SAMＥＯＲIＧIN;

．。

。

可以加在location

..。

ｌoｃation/

｛

　　　　add_headerX-Framｅ-ＯpｔioｎsSAMEORIGIN;

}

。

。

．

1.6服务器启用了TRACE方法

1.6.1解决办法

1.6.1.1ａｐache

２.0.55版本以后

http。

cｏnf

．．。

TraceＥnableofｆ

.．。

２.0.5５版本以前

htｔp。

coｎf

。

。

.

LｏadModｕｌereｗｒite_mｏｄulｅmodulｅs/moｄ_ｒewriｔe。

so　

。

。

。

在各虚拟主机的配置文件里添加如下语句：

。

.．

RｅwritｅEnｇｉneOn

RewriteCond％｛REQUEＳT＿ＭETHOＤ｝^（TＲAＣE｜TＲＡCＫ）

RｅwｒiteRule　.*　-　［Ｆ]

..．

1.6.1.2ｎgiｎx　

nginx.coｎf

.。

.

#限制访问的方法

if（$rｅquｅｓt_meｔhod！

～^（GＥT|HEＡＤ｜POST）$）{

　　returｎ　40３；

｝

。

..

可以加在serｖer

..．

sｅｒvｅr{

.．。

　　iｆ（$reｑuest_method!

~^（GＥＴ|ＨEAＤ|POST）＄）{

　　　retｕrn403；

}

。

．。

｝

.。

。

1.7隐藏服务器版本号

1.7.1解决办法

1.7.1.1ａpache

ｈttp．conｆ或者　http—defaulｔ。

conｆ

。

．．

SｅrｖｅrＴokensPｒod。

。

.

1.7.1.2ngｉnx

nginx。

conf

...

seｒver_toｋensoff;

。

.．

可以加在ｈtｔp

.。

。

http｛

。

．。

ｓerver＿toｋｅｎsｏff；

。

..

}

。

.．