Kotlin与安全性：如何告别SQL注入和XSS

你的代码处于瞄准镜下：为什么Kotlin中的安全性不是可选项，而是必需品

想象一下：你编写了一个完美的应用程序。漂亮的界面、闪电般的速度、清晰的架构。但在一行代码中隐藏着一个“后门”。攻击者在搜索框中输入' OR '1'='1——你的数据库就像罐头一样被打开了。熟悉吗？如果不熟悉——那太好了。但最好提前做好准备，而不是在生产环境中救火。

Kotlin是一种强大且现代的语言。但像任何其他工具一样，它默认不会让你的代码变得安全。SQL注入和XSS（跨站脚本攻击）多年来一直位居OWASP Top 10前列。而那些认为“我使用ORM，没什么好担心的”的Kotlin开发者，往往处于风险之中。

在本文中，我们将探讨如何将你的Kotlin代码变成一座坚不可摧的堡垒。没有废话——只有实用的建议、真实的示例和你可以立即应用的技巧。

Kotlin中的SQL注入：攻击剖析与防御策略

漏洞是什么样子的（以及为什么它很可怕）

当用户输入直接进入SQL查询时，就会发生SQL注入。假设你有这样的代码（永远不要这样做！）：

fun getUserById(id: String): User? {\n    val query = "SELECT * FROM users WHERE id = '$id'"\n    val statement = connection.createStatement()\n    val result = statement.executeQuery(query)\n    // ...\n}

如果攻击者传入id = "1'; DROP TABLE users; --"，数据库将执行：SELECT * FROM users WHERE id = '1'; DROP TABLE users; --'。你的用户将消失。一去不复返。

规则#1：始终使用参数化查询

这是黄金标准。Kotlin（和Java）提供了PreparedStatement，它将SQL代码和数据分开：

fun getUserByIdSafe(id: String): User? {\n    val query = "SELECT * FROM users WHERE id = ?"\n    val preparedStatement = connection.prepareStatement(query)\n    preparedStatement.setString(1, id)\n    val result = preparedStatement.executeQuery()\n    // ...\n}

数据库分别接收查询模板和数据。即使id中带有恶意代码，它也会被解释为字符串，而不是命令。

规则#2：正确使用Exposed或其他ORM

Exposed库是Kotlin的热门选择。如果正确使用其API，它是安全的。糟糕的示例（原始拼接）：

// 糟糕：存在漏洞\nval users = transaction {\n    exec("SELECT * FROM users WHERE name = '$userInput'")\n}

好的示例（使用Exposed的DSL）：

// 好：内置转义\nval users = transaction {\n    Users.select { Users.name eq userInput }\n}

在Exposed中，eq操作符会自动转义值。但如果你通过exec编写原始SQL查询——请保持警惕。

规则#3：输入验证是你的第二道盾牌

即使使用参数化查询，也不应该让所有内容都进入数据库。使用Kotlin内置的检查工具：

fun validateUserId(id: String): Boolean {\n    // 检查id是否为UUID或整数\n    return id.matches(Regex("^[a-fA-F0-9-]{36}$")) || \n           id.all { it.isDigit() }\n}

记住：不要信任任何输入。即使它来自你自己的前端。尤其是当它来自你自己的前端时。

XSS攻击：如何防止JavaScript代码劫持你的网站

什么是XSS以及为什么Kotlin不会自动保护你

XSS（跨站脚本攻击）是指攻击者将脚本注入到你的页面中。例如，在评论字段中，他写下：<script>alert('你的数据被盗')</script>