Lichess | 报告 #3175928 - 图片上传端点中的ImageId格式注入
时间线
ID验证黑客oblivionsage向Lichess提交报告
2025年6月3日 14:51 UTC
摘要
尊敬的Lichess团队:
我在图片上传端点发现了一个输入验证问题,允许我在rel参数中注入特殊字符。这破坏了应用程序用于识别上传图片的预期ImageId格式。在测试上传功能时,我注意到冒号字符没有经过适当清理,这可能导致应用程序其他部分的解析问题。
描述
/upload/image/user/{rel}
端点没有正确验证rel参数。该参数与随机字符串组合创建ImageId,应遵循特定格式:{rel}:{random12}:{random8}.{extension}
问题在于应用程序接受rel参数中的冒号字符而不进行清理。这是因为验证只检查MongoDB注入模式(如$ne),但忽略了破坏格式的字符。
查看modules/memo/src/main/Picfit.scala
中的代码:
|
|
当我注入冒号时,不是获得预期的3部分格式,而是获得多个部分,这可能会破坏其他地方的解析逻辑。
复现步骤
- 登录Lichess并获取会话cookie
- 创建小型测试图像文件(test.png)
|
|
- 发送此请求:
|
|
预期结果:应用程序应拒绝请求或清理冒号
实际结果:请求成功并返回:
正常请求:
|
|
注入请求:
|
|
|
|
注意ImageId现在有6个部分而不是预期的3个:test:evil:format:break:ePU9oRLnNvCz:iFZRITKQ.png
缓解措施
要修复此问题,您应该在图片上传处理程序中清理rel参数。例如:
|
|
或者在PicfitApi.scala
的uploadSource
方法中添加验证,拒绝包含冒号或其他破坏格式字符的rel值。
还应考虑记录预期的ImageId格式,因为当前代码假定特定结构,如果格式更改可能会破坏。
影响
攻击者可能会在应用程序其他期望ImageId遵循标准3部分格式的部分造成问题。我注意到findInMarkdown
中有正则表达式解析逻辑,可能无法正确处理格式错误的ImageId。
这可能会在日志记录、图像查找或markdown解析中造成问题,其中imageId的格式被隐式假定。在生产环境中,如果链式处理程序或分析依赖此结构,这可能导致边缘情况错误或静默失败。
但是,除了破坏数据格式外,我无法证明具体的安全影响。图片仍然成功上传并正确存储。
感谢您的时间并审核我的报告。
附件
4个附件:F4409970: image.png, F4409974: image.png, F4409975: image.png, F4409976: image.png
后续更新:
- 2025年6月3日 15:05 UTC:oblivionsage说明使用自己的账户测试以避免影响他人
- 2025年6月4日 08:44 UTC:Lichess员工shrimpmode修复问题并部署
- 2025年6月4日 09:36 UTC:oblivionsage确认修复有效
- 2025年6月6日 15:02 UTC:报告公开披露
报告详情:
- 报告时间:2025年6月3日 14:51 UTC
- 报告者:oblivionsage
- 严重程度:中等(6.1)
- 弱点:不当的输入验证
- CVE ID:无
- 赏金:隐藏