概述

在做企业生产网络安全相关工作时，首先考虑的就是对服务器端口的管控。可以这么说，中小型企业如果能对服务器端口做严格管控，极大程度上缩小了攻击面，那么入侵事件会相应少很多，对处于救火阶段的安全建设起到立竿见影效果，有点四两拨千斤的味道，值得安全人员花心思在上面。

开放端口

大致上可以定下如下规则：

• 非业务端口一概不对外开放

可以在防火墙或其他网络设备上默认拒绝所有端口的（入/出）流量，然后再针对业务添加需要开放的端口，这样避免了管理工作上的混乱。

• 管理端口必须经过内部统一认证登录，必要时可以加上二次验证。

如果有堡垒机当然最好了，我在开发运维跳板机的过程就嵌入了 Google Authenticator 二次验证因子，使得员工登录服务器除了验证静态密钥外，还需要验证动态密码。

• 对那些开放外网权限的服务，需要做深入的渗透测试。

当然这并不能说要求渗透测试找出所有安全问题，这是不可能的，但是要保证不能携带高危漏洞上线，并且要求做到在收到安全告警时能迅速定位到问题，这才是最主要的。

严格按照上面的规则执行，抵御一些脚本小子的恶意攻击还是绰绰有余的。

0x01

内部一次渗透测试中发现页面提供了富文本输入功能，经过简单的测试发现存在 XSS 问题，这里把考虑的防御方案记录一下。

0x02

富文本的情况和我们平常遇到的一些 XSS 案例不一样，不是简单的在输出位置做针对性过滤就行的，因为既然提供富文本编辑器，那么肯定是内容需要支持某些标签输入输出，如果 XSS FILTER 直接干掉了标签，会影响到内容的展示，所以有必要对富文本情况拎出来单独处理。

有人说用黑名单处理，过滤掉那些危险的标签，那么你会掉进一个有无限 case 要处理的坑里，暂且不说能把现有的危险标签罗列完整，H5 出来后新增的那些标签特性简直就是噩梦。另外，就算考虑再周到，也要知道这个世界上还有一款浏览器叫做 IE，奇葩的解析方式简直让人防不胜防，完全不按套路出牌。

概述

关于如何启用 CSRF 防护，Codeigniter(CI) 官方文档有详细说明。

CSRF 的防御一般比较通用的方案有：

• Referer验证
• Token验证
• 验证码防御

Referer 验证用起来比较简单，但由于各浏览器在 Referer 字段上有着不同的标准，再加上部分验证代码存在逻辑漏洞，所以，一直以来这个方案存在被绕过的风险，效果不是特别理想。而验证码防御的方案又对用户体验有比较大的影响，所以目前来说，基于 token 的验证是最为可用的 CSRF 防护方案，大量开源框架都采用这种方式来抵御 CSRF 攻击的。当然，也有组合这几种的防御方案，效果比单一使用某一方案更优。

CI & CSRF

CI 默认并未开启 CSRF 防御

1
2

// /application/config/config.php
$config['csrf_protection'] = FALSE;

若将该值设置为TRUE，则 CI 会对每个 POST 请求进行 CSRF Verify

1
2
3
4
5
6

// /system/core/Input.php
		// CSRF Protection check
		if ($this->_enable_csrf === TRUE && ! is_cli())
		{
			$this->security->csrf_verify();
		}

概述

现在甲方的安全工作很大一部分都是围绕防御来做的，而攻防之间本来就信息不对称，因为攻只需一个点，而防得一个面，迫使防御方需要能早知道攻击者的行为，才能针对性设防，这就使得安全工作经常处于被动局面。结合互联网已公开的一些漏洞来看，很有必要为企业建立一套适合自身业务的安全基线，并严格执行，减少低级漏洞的产生，这样安全工程师才会有更多的精力放在对抗上，从而扭转部分被动局面。

安全基线

认证与鉴权

错误提示

登录错误必须统一字样，比如用户名或密码错误时，返回“错误的用户名或密码”。

服务端抛出的错误禁止直接返回给接口，仅返回“Error”字样，错误内容打到相关服务日志。

0x01

我在某次授权渗透时候碰到的场景：

渗透对象：

某电商 APP

目标缺陷：

API 设计不合理导致可泄露业务相关敏感信息

测试过程：

APP 含有购买功能，购买后会为订单生成订单号，此处订单号并不连续且为纯数字。为了进行越权测试，我注册了两个账户，分别进行一次购买行为。测试时我用 Burp 截取查看订单功能的数据包，并修改 URL 中的订单号为任意数字，向服务端再次提交请求，经过多次测试，发现服务端的返回请求状态码不是 403 就是 404，基本可以确定此处不存在订单越权查看问题，但是根据服务端返回的状态码，不难推测出如下结论：

404 即该订单号对应的订单不存在

403 即该订单存在，但不允许我查看

State-Of-The-Art OAuth2 Homakov Edition

考虑到官方OAuth2规范的脆弱性以及易受攻击的服务提供商和客户端的集成数，有了满足secure-by-default原则的OAuth版本-Homakov

CSRF防护初始请求/connect/provider的时候，总是使用和需要state参数，不允许动态的redirect_uri，默认不允许response_type=hash（以前是token），废弃refresh_token和token，而不是用appsecret_proof去认证每个access_token，仔细检查用户想要连接的服务提供商账户，access_token永不过期（把它当做公开的user_id）

1、用户点击连接服务提供商的按钮，无论是发起一个POST表单提交（受CSRF Token防护的）到/connect/provider_name，还是由GET导航到/connect/provider?csrf_token=TOKEN，初始步骤一定要受CSRF防护，它不应该被来自其他源的连接触发，必须有来自于用户的明确的确认。

2、在服务端/connect/provider客户端的控制器应该确认csrf_token和来自于session里的token一致，然后生成state token（CSRF Token，确保OAuth流程完整性），并命名为<provider>-state存储在session里。然后跳转到provider.com/oauth/authorize?client_id=CLIENT_ID&redirect_uri=CLIENT/callback&state=STAT，scope参数是可选的（应该仅仅允许被认证过的客户端接触一些关键的作用域）

概述

GNU wget 低于1.18版本均存在任意文件上传/可能还会造成远程代码执行CVE-2016-4971。当提供给wget一个恶意的url时，wget（版本低于1.18）会执行url所指向的webserver返回头中的30x跳转，造成wget会保存攻击者提供的任意远程文件。

验证

环境

webserver 10.0.97.225/192.168.1.148

logserver 10.0.97.243/192.168.1.149

步骤

在webserver上起了个nginx，nginx.conf里配置了一个302跳转，另外还起了一个ftp服务，监听21端口，python -m pyftpdlib -p21 -w

logserver上wget版本信息

如果问一个安全/程序员如何才能防 SQL 注入问题？我想大部分人都会提到使用参数化查询，那是不是这样就高枕无忧了呢？换句话说是不是使用参数化查询后就能杜绝一切 SQL 注入问题呢？答案是否定的，参数化查询是针对参数值的绑定技术解决注入问题，而 SQL 语句中某些字段位置并不支持绑定技术，比如 ORDER BY 关键字后跟列名。当该列名的输入对用户可控时，在 SQL 注入问题上，参数化查询就束手无策了。

验证漏洞

查找疑似和 ORDER BY 关键字有关的参数，构造合适 Payload：

1
2

orderby=ASC,if(1=1,1,(select 1 from information_schema.tables))&key=value
orderby=ASC,if(1=2,1,(select 1 from information_schema.tables))&key=value

因为 select 1 from information_schema.tables 会返回多个行，MySQL 会报“ERROR 1242 (21000): Subquery returns more than 1 row” 的错误，从而整条语句执行失败将无结果返回。

漏洞分析