Android访问Windows WebService时客户端IP获取及防伪造方案咨询

既然你同时攥着客户端和服务端的开发权限，这可是个大优势——咱们完全可以通过两端协同验证，把IP伪造的风险压到最低，不用再纠结单一来源的可靠性。下面是几个实用的方案，按优先级给你理清楚：

1. 以服务端获取的TCP层IP为核心，辅以客户端上报IP做校验 #

首先得搞明白两个IP的本质区别：

• 客户端自己上报的IP是应用层数据，想怎么改就怎么改，完全没可信度；
• 服务端通过HttpContext.Current.Request.UserHostAddress（ASP.NET环境）拿到的是TCP连接的源IP，这个是网络层协议栈提供的，普通恶意客户端根本没法直接伪造（除非用代理、VPN，或者搞成本极高的IP spoofing攻击，但后者很难针对WebService持续操作）。

所以核心玩法是：

• 服务端把自己拿到的TCP源IP当作基准；
• 客户端同时上报自己检测到的本地IP（比如通过WifiManager或NetworkInterface捞的内网/公网IP）；
• 服务端做合理性校验：
  • 如果客户端是直连服务端（没走代理），那客户端上报的公网IP应该和服务端拿到的IP完全一致；
  • 如果客户端走了代理（比如运营商中转、VPN），服务端可以通过X-Forwarded-For这类头部拿真实IP，但一定要配置信任的代理列表，防止恶意客户端伪造这个头部；
  • 要是两者差异太离谱（比如客户端报的是完全不搭边的IP段），直接标记为可疑请求，触发二次验证。

2. 给请求加签名锁，确保只有合法客户端能发起请求 #

既然你控制客户端代码，那给每个请求加个密钥签名就很靠谱——恶意客户端就算能伪造IP，拿不到你的签名密钥，请求根本过不了服务端的关。具体步骤：

• 在Android客户端里，把请求参数（包括客户端上报的IP）、时间戳拼在一起，用预设的密钥做HMAC-SHA256加密，生成签名字符串；
• 把签名和时间戳一起塞到请求头或者参数里发给服务端；
• C#服务端收到请求后，用同样的密钥、同样的拼接规则重新生成签名，和客户端传过来的比对：
  • 签名不一致？直接拒绝；
  • 顺便校验时间戳，防止重放攻击（比如拒绝5分钟前的请求）。

给你贴个简单的代码片段参考：

Android客户端（Kotlin） #

fun generateRequestSignature(params: Map<String, String>, timestamp: Long, secretKey: String): String {
    val sortedParams = params.toSortedMap()
    val sb = StringBuilder()
    sortedParams.forEach { (key, value) -> sb.append("$key=$value&") }
    sb.append("timestamp=$timestamp")
    val content = sb.toString()
    return HmacUtils.hmacSha256Hex(secretKey, content)
}

C#服务端 #

public string GenerateSignature(Dictionary<string, string> parameters, long timestamp, string secretKey)
{
    var sortedParams = parameters.OrderBy(kv => kv.Key).ToList();
    var sb = new StringBuilder();
    foreach (var kv in sortedParams)
    {
        sb.Append($"{kv.Key}={kv.Value}&");
    }
    sb.Append($"timestamp={timestamp}");
    var content = sb.ToString();
    using (var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(secretKey)))
    {
        var hashBytes = hmac.ComputeHash(Encoding.UTF8.GetBytes(content));
        return BitConverter.ToString(hashBytes).Replace("-", "").ToLower();
    }
}

3. 结合设备唯一标识做辅助校验 #

在合法客户端里，你可以捞一些难伪造的设备标识（比如Android的AndroidId，注意Android 10+不让随便拿IMEI了），把它和IP、签名一起发给服务端。服务端可以建个“设备标识-常用IP段”的关联库，要是某个设备突然用完全陌生的IP段发起请求，就触发额外验证（比如验证码、二次签名）。

提醒下：设备标识可能因为刷机、重置变掉，所以只能当辅助手段，不能单独靠它。

4. 极端情况的补漏措施 #

• 如果你的服务端部署在反向代理（比如Nginx）后面，一定要让代理把真实客户端IP传给WebService，比如在Nginx里加proxy_set_header X-Forwarded-For $remote_addr;，同时在C#服务端里只信任来自你自己代理的X-Forwarded-For头部，别让恶意客户端随便伪造；
• 给可疑请求限流拉黑：要是某个IP短时间内狂发请求，或者多次出现IP和签名不匹配的情况，直接暂时拉黑这个IP。

总结下来，服务端拿到的TCP源IP是最可靠的基础，再加上请求签名验证，普通恶意客户端的IP伪造问题基本就解决了——毕竟伪造IP容易，拿到你的签名密钥可难多了。

内容的提问来源于stack exchange，提问作者Ton