一、什么是Cypher注入？为什么要防范？
很多刚接触图数据库（比如Neo4j）的开发者，会像处理MySQL这类关系数据库一样，写查询语句时直接把用户输入的内容拼到Cypher里，殊不知这是一个非常危险的操作，会触发Cypher注入漏洞，就像关系数据库里的SQL注入一样，可能被攻击者用来删除数据、窃取信息，甚至接管整个数据库。
1.1 举个实际的“坑”例子
假设我们做了一个简单的用户查询功能，输入用户名就能找到对应的用户信息。如果开发者图省事，直接把用户输入的用户名拼到查询语句里，就会埋下隐患。
我们先看错误的写法，这里用Python做示例： 技术栈：Python 3.9 + neo4j驱动 4.4
from neo4j import GraphDatabase
# 连接数据库
driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))
# 错误的写法：直接拼接用户输入
def get_user_wrong(username_input):
# 把用户输入的username直接拼到Cypher语句里
cypher_query = f"MATCH (u:User) WHERE u.name = '{username_input}' RETURN u.name, u.email"
with driver.session() as session:
result = session.run(cypher_query)
return [record.data() for record in result]
# 正常测试：用户输入用户名"alice"，会返回alice的信息
print(get_user_wrong("alice"))
# 恶意输入测试：如果用户输入"alice'; MATCH (u:User) DELETE u; RETURN '1"
# 拼出来的完整Cypher会变成：
# MATCH (u:User) WHERE u.name = 'alice'; MATCH (u:User) DELETE u; RETURN '1' RETURN u.name, u.email
# 这时候数据库会先查询alice，然后执行删除所有User节点的操作，把所有用户删光！
这个例子很直观，用户输入的内容被拆成了Cypher语句的一部分，多执行了恶意命令，这就是Cypher注入的典型场景。
1.2 注入的危害到底有多大？
除了刚才的删除数据，攻击者还能做很多坏事：比如篡改用户邮箱、窃取所有用户的隐私信息、甚至修改数据库的权限配置，让攻击者可以完全控制你的图数据库。对于需要存储用户数据、订单信息的业务来说，这种漏洞是致命的，轻则数据泄露，重则业务停摆。
二、解决方法：参数化查询，不是拼字符串
既然直接拼字符串这么危险，那正确的做法是什么？答案就是参数化查询，也就是把Cypher语句的结构和用户输入的数据分开，语句是“模板”，输入是“独立的数据”，两部分不会混合，这样用户输入的内容再怎么怪，也只会被当成普通数据，不会被当成查询的一部分执行。
2.1 参数化怎么用？先看正确和错误的对比
还是刚才的用户查询功能，用参数化的写法，就完全不一样了：
from neo4j import GraphDatabase
driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))
# 正确的写法：用参数绑定
def get_user_right(username_input):
# Cypher里用$username作为参数占位符，不是直接拼变量
cypher_query = "MATCH (u:User) WHERE u.name = $username RETURN u.name, u.email"
with driver.session() as session:
# 把用户输入的数据作为参数传入，驱动自动做安全校验
result = session.run(cypher_query, parameters={"username": username_input})
return [record.data() for record in result]
# 恶意输入测试：用刚才的恶意内容测试，结果完全不同
print(get_user_right("alice'; MATCH (u:User) DELETE u; RETURN '1"))
# 这时候用户的整个输入会被当成u.name的值，找不到对应用户，只会返回空，完全不会执行删除！
2.2 为什么参数化能防注入？（通俗讲原理）
原理一点都不复杂，举个生活化的例子：你点外卖的时候，告诉商家“我要一份加冰的可乐”，商家就只给你做加冰的可乐，不会自作主张加别的东西。参数化就像你和商家用“点餐模板”沟通：模板是“我要一份 [x] 的 [y]”，x是你的“加冰”，y是“可乐”，商家只会把x和y当成具体内容，不会拆成别的指令。
而直接拼字符串就像你对着商家喊“我要一份加冰的可乐，顺便帮我寄一份外卖给隔壁老王”，商家把你喊的所有内容都当成指令，就会执行多余操作——这就是注入的本质。
三、常见的错误做法和避坑指南
很多开发者知道要防注入，但用错了方法，或者踩了别的坑，比如下面两种最常见的错误：
3.1 错误做法一：只过滤特殊字符，比如单引号
有人觉得注入是因为单引号，所以只要把单引号转义就行，或者过滤掉';、--这些特殊字符。但这种方法完全没用，攻击者可以用Unicode字符绕过滤，比如用%27代替单引号，或者用//把后面的内容注释掉，而且手动过滤工作量大，容易漏。
3.2 错误做法二：不知道哪些地方可以用参数化，哪些不能
参数化确实好用，但有个限制：只有值属性（比如u.name、u.age这类属性的值）可以用参数，标识符（比如节点标签:User、关系类型:FOLLOW这类）不能用参数。比如要让用户输入要查询的节点标签，用户输入Product，要写MATCH (p:Product)，这时候不能用参数，因为标签是标识符，参数只能传值，不能传标识符。
这时候只能用白名单校验：提前把允许的标签列出来，比如allowed_labels = ["User", "Product", "Order"]，把用户输入的标签和白名单对比，只有在列表里才用，否则直接返回错误，拒绝执行查询。
四、实际应用场景和最优实践
参数化查询适合大部分场景，我们来看看实际开发中最常用的场景怎么用，还有要注意的地方：
4.1 常规增删改查场景怎么套参数化？
比如添加用户节点的场景，Cypher语句是CREATE (u:User {name: $name, email: $email})，用参数的话，只要把name和email作为参数传入就行：
def add_user(username, email):
query = "CREATE (u:User {name: $name, email: $email}) RETURN u.id"
with driver.session() as session:
result = session.run(query, parameters={"name": username, "email": email})
return result.single()["u.id"]
还有查询用户的关联关系，比如找某用户关注的人，语句是MATCH (u:User)-[:FOLLOW]->(f:User) WHERE u.name = $username RETURN f.name，同样用参数传username，不需要拼字符串。
4.2 注意事项：别踩这几个细节坑
第一，不管用什么语言的neo4j驱动，都要确认参数化的写法，比如Java驱动用session.run(query, Map.of("name", username))，JavaScript驱动用session.run(query, {name: username})，核心都是把参数和语句分开，不要拼字符串。
第二，标识符的白名单必须严谨，标签、关系类型如果是用户输入的，都要做白名单校验，比如允许的关系类型是FOLLOW、BUY，不能允许别的类型。
第三，不要用用户输入的内容作为Cypher的函数名，比如用户输入要调用length()函数，这种情况不管用不用参数化都要过滤，因为函数名也是标识符，不能用参数。
五、文章总结
Cypher注入是图数据库应用里非常常见的安全漏洞，核心防范手段就是用参数化查询，把语句结构和用户输入的数据分开，而不是直接拼字符串。同时要注意，标识符（标签、关系类型等）不能用参数化，必须用白名单校验，不能自己手动过滤特殊字符。只要做到这几点，就能避免大部分Cypher注入的风险，构建安全稳定的图数据库应用。
评论
围绕“Cypher查询中的参数化与注入防范：构建安全图数据库应用的关键要点”参与讨论