在使用 GitHub Webhooks 时，为了保证服务器安全，可以仅允许 GitHub 的授权 IP 访问您的应用程序。GitHub 提供了一个 API，可以动态获取这些 IP 范围。本文将展示如何获取 GitHub 的 IP 并自动更新服务器的 iptables 规则。 环境要求 系统工具： curl：用于发送 HTTP 请求。 jq：用于解析 JSON 响应。 使用以下命令安装： 12sudo apt updatesudo apt install -y curl jq 管理员权限： 您需要 root 权限或 sudo 权限来修改 iptables 规则。 第一步：了解 GitHub Meta API GitHub 提供了一个元数据 API 端点，其中包括 GitHub Webhooks 使用的 IP 范围： API 地址： 1https://api.github.com/meta 返回数据中的 hooks 字段包含 Webhooks 请求所需的 IP 范围。 第二步：编写脚本 以下是一个 Bash 脚本，用于动态获取 GitHub 的 IP 范围并更新 ip ...

前言 最近一位搞网络安全的朋友问我，为什么用 PreparedStatement 预编译的 SQL 就不会有被 SQL 注入的风险？ 初听之下，我想到了面试八股文中关于 MyBatis 的 ${} 和 #{} 区别的问题，但再细想其中缘由，却不甚明了。 于是，我决定研究一下：预编译到底是什么？它如何与数据库交互？PreparedStatement 在这一过程中又做了什么？ 一、数据库预编译 1. 什么是预编译 SQL？ 以 MySQL 为例，所谓预编译是指先提交带占位符的 SQL 模板，数据库为其生成一个 key 并进行编译，随后用户通过 key 和参数让数据库执行完整的 SQL。类似于 Python 的 format 函数。 示例如下： 123PREPARE stmt FROM 'SELECT * FROM users WHERE username = ?';SET @name = 'john';EXECUTE stmt USING @name; 最终执行的 SQL： 1SELECT * FROM u ...

前言 SQL 注入漏洞是 Web 安全中最常见的问题之一。在 Java 中，由于预编译技术和各种 ORM 框架的普及，SQL 注入问题虽然有所减少，但仍然存在隐患。对于新手代码审计者而言，面对 Java Web 应用中多个框架的复杂组合，往往无从下手。本文以 MyBatis 框架中使用不当导致的 SQL 注入问题为例，希望能为新手提供一些启发。 一、MyBatis 的 SQL 注入问题 MyBatis 的 SQL 语句可以通过注解写在类的方法上，也可以通过 XML 文件编写。SQL 语句需要手动编写或使用代码生成工具（如 MyBatis Generator）生成。MyBatis 支持两种参数占位符：# 和 $，分别表示预编译和字符串拼接。例如： 123<select id="queryAll" resultMap="resultMap"> SELECT * FROM NEWS WHERE ID = #{id}</select> 其中，# 使用预编译，而 $ 则直接拼接 SQL。 在 MyBatis ...

在Spring Boot中，可以通过使用参数绑定、预处理语句和使用ORM框架等方式来防止SQL注入。以下是几种常见的方式： 参数绑定 通过使用参数绑定，将用户输入的数据作为参数传递给SQL语句，而不是将其直接拼接到SQL语句中。Spring Boot的JdbcTemplate和Spring Data JPA等库都提供了参数绑定的支持。 12345String username = ...String password = ...String sql = "SELECT * FROM users WHERE username = ? AND password = ?"Object[] params = {username, password};jdbcTemplate.queryForObject(sql, params, User.class); 预处理语句 使用预处理语句可以避免直接将用户输入的数据拼接到SQL语句中。预处理语句会在执行之前预先编译SQL语句，并使用参数占位符代替实际的参数值。 1234567String userna ...

什么是 SQL 注入 (SQi)？ 结构化查询语言 (SQL) 注入是一种代码注入技术，用于修改或从 SQL 数据库检索数据。通过在输入字段中插入专用的 SQL 语句，攻击者可以执行命令，以允许从数据库中检索数据、破坏敏感数据或执行其他操纵行为。 通过正确执行 SQL 命令，未经授权的用户可以伪造特权更高的用户的身份，使自己或其他人成为数据库管理员，篡改现有数据、修改事务和余额以及检索和/或销毁所有服务器数据。 在现代计算中，SQL 注入通常在互联网上发生，攻击者向网站或服务提供的 API 端点发送恶意 SQL 查询（下文将详细介绍）。在最严重的形式下，SQL 注入可以使攻击者获得对计算机的 root 访问权限，完全掌握控制权。 SQL 是用于维护大多数数据库的编程语言。 SQL 注入攻击的工作原理 想象一个法庭，一个名叫 Bob 的男子受审，他即将在法官面前出庭。在庭审前填写文书时，Bob 将自己的名字写成“Bob 可以自由离开”。当法官审理其案件并大声读出“下面传唤的人是‘Bob 可以自由离开’”时，法警放开 Bob，因为法官说他可以自由离开了。 尽管 SQLi 的各个变版略有不同 ...

跨站点脚本 (XSS) 攻击在整个互联网中广泛存在。它们可用于冒充用户、窃取私人信息、破坏网站等等。那么 XSS 攻击到底是什么？为什么它是一种安全威胁？以及如何防止跨站点脚本攻击？ 什么是跨站点脚本攻击？ 跨站点脚本，通常称为 XSS，是一种 Web 应用程序安全漏洞，允许攻击者向网页注入任意客户端代码或脚本。 当毫无戒心的用户与受感染的网页进行交互时，就会触发注入的代码，受害者就会受到攻击，这种攻击可能会窃取敏感信息或以受害者的利益为代价进行未经请求的交易。 恶意脚本可以伪装成用户，窃取信息和 cookie，操纵网站内容，破坏网站并将受害者重定向到恶意网站。 XSS 攻击并不新鲜。它们最早出现在 1990 年代，从那时起就一直被开放 Web 应用程序安全项目(OWASP)列为十大网络安全风险之一，2021 年报告的 XSS 攻击次数超过 274,000 次。 XSS 攻击如何工作？ XSS 攻击与网站无法清理输入数据有关。这意味着网站无法正确地从其接受的输入中剥离 HTML 内容。 为什么这很糟糕？您的网络浏览器无法区分原始网站代码和注入的代码。因此，如果攻击者输入恶意脚本（Jav ...

Apache FreeMarker™ 是一个模板引擎：一个 Java 库，用于根据模板和不断变化的数据生成文本输出（HTML 网页、电子邮件、配置文件、源代码等）。模板是用 FreeMarker 模板语言 （FTL） 编写的，FTL 是一种简单的专业语言（不是像 PHP 那样成熟的编程语言）。通常，使用通用编程语言（如 Java）来准备数据（发出数据库查询、进行业务计算）。然后，Apache FreeMarker 使用模板显示准备好的数据。在模板中，您关注的是如何呈现数据，而在模板之外，您关注的是要呈现的数据。 这种方法通常被称为 MVC（模型视图控制器）模式，在动态网页中特别流行。它有助于将网页设计人员（HTML 作者）与开发人员（通常是 Java 程序员）区分开来。设计人员不会在模板中遇到复杂的逻辑，并且可以更改页面的外观，而无需程序员更改或重新编译代码。 虽然 FreeMarker 最初是为了在 MVC Web 应用程序框架中生成 HTML 页面而创建的，但它并不绑定到 servlet 或 HTML 或任何与 Web 相关的东西。它也用于非 Web 应用程序环境。 FreeMa ...

前言 Spring Initializr从本质上来说就是一个Web应用程序，它能为你生成Spring Boot项目结构。虽然不能生成应用程序代码，但它能为你提供一个基本的项目结构，以何种编程语言（Java,Kotlin,Groovy）构建的Maven或Gradle构建说明文件。你只需要写应用程序的代码就好了。 Spring Initializr 有几种用法。 通过Web界面使用。 通过Spring Tool Suite使用。 通过IntelliJ IDEA使用。 使用Spring Boot CLI使用。 本例主要讲解Web界面和IntelliJ IDEA的使用。 搭建本地start.spring.io 前提条件 确保本地已安装maven环境变量且settings.xml已添加aliyun源 123456<mirror> <id>nexus-aliyun</id> <name>Nexus aliyun</name> <url>http://maven.aliyun.com ...

一般项目上常用Nginx做负载均衡和静态资源服务器，本案例中项目上使用Nginx作为静态资源服务器出现了很奇怪的现象，我们一起来看看。 “诡异”的现象 部署架构如下图，Nginx作为静态资源服务器监听8080端口，客户浏览器通过API网关的443端口（就是https）获取Nginx静态资源。 现象是用户浏览器访问WAF的https地址后，WAF将请求SSL解密再请求Nginx 8080端口的/categories路径，但返回给客户端的却是 https://www.yihuo.tech:8080/categories/ !!! 这还是个重定向响应，响应头里包含 Location: https://www.yihuo.tech:8080/categories/，由于API网关并没有开放这个端口号，所以请求到这里就无法继续下去了。 问题分析 后来根据浏览器F12打开调试窗口的network看到原来如此 这里就很明确是Nginx返回的301永久重定向，Nginx使用自己端口号暴露出来做的重定向。到此问题已清晰，只要不让Nginx把端口号暴露出来就可以了。 问题原因 这得先从Nginx的处理 ...