服务器端应用安全

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_22329521/article/details/76128654

SQL注入

盲注

Web服务器关闭了错误回显,对于攻击者就缺少了重要的调试信息,所以攻击者知道一个方法来验证SQL语句是否执行
比如

http://xxxx.com/items.php?id=2
构造
http://xxxx.com/items.php?id=2 and 1=2
如果页面是空的,或者出差,可以猜测这可能存在注入的机会
再次修改
http://xxxx.com/items.php?id=2 and 1=1
如果正常返回,就可以判断注入成功

BENCHMARK函数

BENCHMARK函数用来测试函数性能

BENCHMARK(10000000,ENCODE('msg','by 5 seconds'))encode(xxx,xxx)执行xxxx次数

利用BENCHMARK函数,可以让同一个行数执行若干次,使得结果返回的时间比平时长,通过时间长度变化,可以判断注入语句是否执行成功

下面有具体的sql实例
http://blog.csdn.net/emaste_r/article/details/8156108

防御sql注入

  • 预编译语句,绑定变量
  • 使用存储过程,调用存在数据库里的函数
  • 检查数据类型,如果输入是数字,就用integer做检验,如果是邮箱则正则表达式去做校验等
  • 使用定义好的安全函数来转义。
  • 设置数据库用户的最小权限。

文件上传漏洞

文件上传后导致的常见安全问题一般有:

  • 上传文件是Web脚本语言,服务器的Web容器解释并执行用户上传的脚本,导致代码执行
  • 上传文件是Flash的策略文件crossdomain.xml,黑客用以控制Flash在该域下的行为(其他通过类似行为控制策略文件的情况类似)
  • 上传文件是病毒,木马文件,用以诱惑用户或者管理员下载执行
  • 上传文件是钓鱼图片或为包含脚本的图片,在某些版本浏览器中会被作为脚本执行,被用于钓鱼和欺诈

设计安全的文件上传功能

  • 文件上传的目录设置为不可执行:只要Web容器无法解析该目录下的文件,即使上传了脚本文件也不收影响
  • 判断文件类型:可以结合MIME Type,后缀检查等方式。
  • 使用随机数改写文件名和文件路径:只要修改路径,上传的文件查找的不容易
  • 单独设置文件服务器的域名:同源策略的关系,一系列客户端攻击将生效

用户信息管理

密码强度
  • 普通应用要求长度为6位以上
  • 重要应用要求长度为8位以上,并考虑双因素认证
  • 密码区分大小写字母
  • 密码为大写字母,小写字幕、数字、特殊符号中两种以上的组合
  • 不要有连续性的字符
  • 尽量避免出现重复的字符
  • 密码保存:必须以不可逆的加密算法,或者是单向散列函数算法,加密后存储在数据库中
  • 在计算密码明文的时候加一个salt MD5(salt+password),避免password 单一容易被彩虹表收集到

Session注意点

  • Seesion在登陆完成后,重写SessionId,避免SessionFixation攻击
  • 服务器设置固定时间强制销毁Session,因为客户端可以修改用户的存活时间,定时拿seesionId去请求。
  • 降低SSO的风险,在一些敏感的系统,在单独实现额外的认证机制。

访问控制

  • 垂直权限管理:现在应用广泛的一种方法是基于角色的范围控制:RBAC,Java中的Spring Security 权限管理,就是RBAC模型的一个实现
  • 水平权限管理,RBAC只能验证用户A属于角色RoleX,但不会判断用户A是否能访问只属于用户B的数据B,发生了越权访问,这种问题一般是具体问题具体解决,至今仍是一个难题,它难以发现
  • 设计方案时,都应该满足“最小权限原则”

加密算法与随机数

略。。。

记下结论

  • 不要使用ECB模式
  • 不要使用流密码(RC4)
  • 使用HMAC-SHA1替代MD5(甚至是替代SHA1)
  • 不要使用相同的key做不同的事情
  • salts与IV需要随机生成
  • 不要自己实现加密算法,尽量使用安全专家已经实现好的库
  • 不要依赖系统的保密性
  • 使用CBC模式的AES256加密
  • 使用HMAC-SHA512用于完整性检查
  • 使用带salt的SHA-256或SHA-512用于Hash

DDOS

DDOS又称为分布式拒绝服务利用合理的请求造成资源过载,导致服务不可用

SYN flood攻击

  1. 客户端向服务器端发送一个SYN包,包含客户单使用的端口号和初始序列号X
  2. 服务器端接受到客户单发送的SYN包后,向客户端发送一个SYN包和ACK都置位的TCP报文,包含确认号x+1和服务器端的初始序列号y
  3. 客户端收到服务器端返回的SYN+ACK报文后,向服务器端返回一个确认号为y+1、序号为x+1的ACK报文,一个标准的TCP连接

SYN flood攻击,首先伪造大量的源IP地址,分别向服务器端发送大量的SYN包,此时服务器端会返回SYN/ACK包,因为源地址是伪造的,所以伪造的IP并不会应答,服务器端没有收到伪造IP的回应,会重试3-5次并且等待一个SYN Time(一般为30秒至2分钟),如果超时则丢弃连接。攻击者大量发送这种伪造源地址的SYN请求,服务器会消耗非常多的资源来处理这种半连接。

对抗SYN flood的主要策略有SYN Cookie/SYN Proxy,safereset等算法,SYN Cookie 主要思想是为每一个IP地址分配一个 cookie,并统计每个ip地址的访问频率,如果短时间收到大量的请求,则丢弃这些ip地址的包

应用层DDOS

由于发生在应用层,tcp三次握手已经完成,连接建立,发起的ip都是真实的,这种ddos逼网络层ddos更可怕
CC攻击
CC攻击原理非常简单,就是对一些消耗资源较大的应用页面不断发起正常的请求,以达到消耗服务器资源的目的。在Web应用中,查询数据库,读/写硬盘文件等操作,相对都会消耗成比较多的资源
应用层的攻击还可以通过一下方式:黑客入侵了一个流量大的网站后,通过篡改页面,将巨大的用户流量分流到目标网站

<iframe src="target" width=0,height=0/>

资源耗尽攻击

Slowloris攻击
其原理是以极低的速度往服务器发送HTTP请求。由于Web Server对于并发的连接数有一定的上限,因此若是恶意地占用住这些连接不释放。那么无法接收到正常的请求
实现是构造一个畸形的HTTP请求

Content-Length:42\r\n\r\n

由于WebServer只收到一个\r\n,因此将认为Http Headers部分没有结束,并保持

优化服务器性能的方式

  • 将使用频率高的数据放到memcache中,将数据库的压力转移到内存中,此外及时释放资源
  • 在针对每个客户端做一个请求频率的限制(但是如果对方使用代理服务器通过不断变化IP地址,如果服务器对单个IP地址的请求就无效了)
  • 在网络架构上做好优化,善于利用负载均衡,避免用户流量集中在单台服务器上,同时可以充分利用好CDN和镜像站点的分流作用,缓解主站的压力
  • 验证码,为了识别人与机器的交互
  • 可以在Http头中的User-Agent字段来识别客户端,让客户端解析一段JavaScript,并给出正确的运行结果等
  • 在WebServer做出一些处理,其好处在于请求尚未到达后端,在Apache的配置文件中,有一些参数可以缓解DDOS攻击,比如调小Timeout,KeepAliveTimeout值,增加MaxClients的值

垃圾处理

如何防范垃圾注册和垃圾消息,垃圾处理离不开
两个步骤:‘识别’和‘拦截’
“批量”和“自动化”的特点意味着:

  1. 同一客户端会多次请求同样的URL地址
  2. 页面与页面直接的跳转流程不支持
  3. 同意客户端两次请求时间短
  4. 客户端的UserAgent看起来不像浏览器
  5. 客户端可能无法解析JavaScript和Flash
  6. 在大多数情况下验证码是有效的

如果在从垃圾注册和垃圾消息的内容分析,发现的特点

  1. 注册时填写的用户名可能是随机生成的字符串,而非自然语言
  2. 不同账号的资料可能出现同样的内容
  3. 可能含有一些敏感词
  4. 可能出现文字变形,比如全角变半角

与业务结合,更多的特征

  1. 如果某个用户给多个用户发送消息,但是接受者不会,这个人可能在发送消息
  2. 如果某个用户加入IM群中,发送的消息是相同的内容,不说其他话,可能也是在发送垃圾消息

有了这些特征,可以建立规则和模型

参考文章
白帽子讲Web安全
http://www.bubuko.com/infodetail-1784365.html
http://blog.csdn.net/emaste_r/article/details/8156108

展开阅读全文

没有更多推荐了,返回首页