WEB 学习框架搭建

优质文章学习记录

— 15 min read
WEB 学习框架搭建

WEB 学习框架搭建

（写了几道web题目，都感觉无法下手，后来觉得还是得系统搭建框架学习，如果连基础知识都有很多不明白，光知道各种注入方法也没有什么用，以下为借助AI的学习记录）

web应用框架

前端（XSS,CSRF）-后端（SQL，越权，文件上传，文件包含。。。）-数据库

场景：用户在小程序上输入手机号和密码，点击“登录”。

第一步：前端的工作 (用户看得见的部分)

前端负责展示界面、收集数据、调用API、处理响应。

  1. 构建界面：画出登录页面，有手机号输入框、密码输入框和“登录”按钮。
  2. 监听事件：用户点击“登录”按钮时，前端代码被触发。
  3. 收集与校验：前端获取输入框里的手机号和密码，先做基本校验（如手机号格式、密码非空）。
  4. 调用API（最关键一步）：** 前端使用 axios 或 fetch 等工具，发送这个请求。这个动作就叫 “调用API”。之后，前端就进入等待状态，控制权转移给后端。
      • API地址 (URL)：https://api.yourservice.com/v1/user/login
      • 请求方法 (Method)：POST
      • 请求头 (Headers)：Content-Type: application/json
        ** 请求体 (Body)：一个JSON对象，里面装着用户数据。

前端按照后端提供的API文档，组装一个HTTP请求。比如：

{"phone_number":"13800138000","password":"encryptedPassword123"}

第二步：后端的工作 (服务器端，用户看不见的黑盒)

后端负责接收请求、处理业务逻辑、操作数据库、返回结果。它通过API来暴露自己的能力。

  1. 接收请求：后端的服务器在 https://api.yourservice.com/v1/user/login 这个地址上监听。收到前端发来的请求后，路由找到对应的处理函数（如 loginController）。
  2. 解析与验证：后端解析请求体中的JSON，并进行严肃的业务验证：
    • 手机号是否存在？
    • 密码是否正确（会与数据库加密存储的密文对比）？
    • 账户是否被锁定？
  3. 处理核心逻辑：
    • 验证通过后，后端生成一个代表用户身份的令牌（Token），并关联这个用户ID。
    • 将这个Token和用户基本信息（昵称、头像）写入数据库或缓存（如Redis）。
  4. 操作数据库：执行SQL语句，如 SELECT * FROM users WHERE phone_number = '13800138000'，查询用户信息。

组装并返回响应：后端处理完毕，按照API文档的约定，组装一个HTTP响应返回给前端。
** 响应体 (Body)：一个JSON对象。

{"code":200,"message":"登录成功","data":{"user_id":12345,"nickname":"张三","avatar":"https://xxx.jpg","token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."// 长长的加密字符串}}

第三步：前端再次工作 (处理结果)

控制权随着API的响应，回到了前端。

  1. 接收响应：前端收到后端的HTTP响应。
  2. 解析结果：前端代码解析响应体中的JSON。
  3. 业务处理：
    • 如果 code 是200（成功），前端将 token 和用户信息保存到本地（如 localStorage），然后跳转到首页。
    • 如果 code 是401（密码错误），前端在页面上弹出提示：“手机号或密码错误”。
  4. 更新界面：根据结果，前端展示成功或失败的提示，并刷新用户所见的界面。

核心分工与API的角色总结

角色职责与API的关系
前端交互与展示。负责“是什么”和“怎么做”。
是什么：这是什么页面？按钮是什么颜色？
怎么做：点击后数据怎么发？收到结果怎么显示？		API的调用方。严格按照API文档的格式“提问”。
后端逻辑与数据。负责“能不能”和“给什么”。
能不能：这个用户能登录吗？密码对吗？
给什么：登录成功后，返回什么数据给前端？		API的提供方。定义API的规则，并实现API背后的所有复杂逻辑。
API (HTTP接口)前后端的“合同”/“菜单”。分工的边界与协作的桥梁。它明确规定了：
1. 地址 (URL)：请求发到哪？
2. 方法 (Method)：是查询(GET)还是提交(POST)？
3. 格式 (Format)：前端怎么传数据(Params/Body)？后端怎么返回数据(JSON结构)？

整个过程就像一个流水线：
前端（客户端） -> （通过API发出请求） -> 后端（服务器） -> （处理业务、操作数据库） -> 后端 -> （通过API返回响应） -> 前端 -> （更新界面）。

API就是这条流水线上的标准化传输带和货物装箱规范，确保前后端两个不同的“工厂”能无缝协同工作。

几个问题：什么是JSON？所以API是前端调用的吗？在网络空间安全中有没有可能跨过前端伪造API调用

1. 什么是 JSON？

JSON 是一种轻量级的数据交换格式，可以理解为一种在网络中传输数据的、人和机器都能看懂的“通用语言”。

  • 全称：JavaScript Object Notation (JavaScript 对象表示法)，但它现在独立于任何语言，几乎所有编程语言都支持。
  • 样子：它看起来就是纯文本，结构是键值对 (key-value) 的集合，和编程里的对象、字典非常像。
  • 作用：它是API通信中最常用的“语言”。前端发送请求时，把数据（如手机号、密码）包装成JSON格式；后端返回结果时，也把数据（如用户信息、状态码）包装成JSON格式。

举例：

{"name":"张三","age":25,"isStudent":false,"hobbies":["阅读","编程","篮球"],"address":{"city":"北京","street":"中关村大街"}}

2. 所以API是前端调用的吗？

是，但不仅仅是。 API 的核心是“接口”，任何能按照约定发送请求的程序，都可以是调用方。

  • 主要调用方：在 Web 开发中，前端（浏览器、手机App、小程序）是最常见的 API 调用者，因为它需要从后端获取数据或提交操作。
  • 其他调用方：
    1. 后端调用后端 (BFF/微服务)：一个后端服务可以调用另一个后端服务的 API 来获取特定数据。比如订单服务调用用户服务API来获取用户详情。
    2. 第三方服务调用：你的合作伙伴可以调用你开放的公开 API。比如气象公司调用你的 API 来获取地理信息。
    3. 脚本或测试工具：开发人员可以用 Postman、cURL 等工具直接调用 API 进行测试。

结论：前端是 API 的主要使用者，但 API 是为所有“客户端” 设计的。这里的“客户端”指任何需要该服务的程序。

3. 网络空间安全中，有没有可能跨过前端伪造API调用？

答案是：不仅有，而且这是 API 安全最主要的威胁之一，也是安全工程师工作的重中之重。

“跨过前端” 是极其常见且容易的。因为任何发送到网络的请求，本质上都是一段遵循 HTTP/HTTPS 协议的数据包。攻击者根本不需要你的前端界面。

常见的伪造/攻击手段：

  1. 直接构造请求：
    • 攻击者用 Burp Suite、Postman、甚至简单的 cURL 命令，就能完全模仿你前端发出的请求。
    • 他可以看到你的 API 地址、参数格式，然后修改参数。比如把转账 API 中的 “amount”: 100 改成 “amount”: 1000000。
  2. 重放攻击：
    • 攻击者拦截一个合法的请求（比如登录请求），然后原封不动地重复发送给服务器。如果服务器没有防御机制，就会认为用户又登录了一次，可能生成新 Token 或被滥用。
  3. 越权访问：
    • 假设查看个人资料的 API 是：GET /api/user/profile?user_id=123
    • 攻击者（自己是用户123）把这个 user_id 改成 124，就可能看到用户124的资料。这就是“水平越权”。
    • 如果是 GET /api/admin/all_users，普通用户如果尝试调用，就可能是“垂直越权”。
  4. 自动化攻击：
    • 用脚本程序（机器人）高速、大量地调用你的 API。比如，用一万个手机号循环调用“发送短信验证码”API，导致你产生巨额费用（短信轰炸攻击）。

后端如何防御？（API安全的核心）

正因为前端完全不可信，所以所有安全校验都必须放在后端。

  • 身份认证：你是谁？
    • Token/Session：登录后，后端颁发一个令牌，后续请求必须携带。后端每次都要验证这个令牌是否有效、是否过期、是否属于当前用户。
  • 授权校验：你能干什么？
    • 在处理关键操作前，后端代码必须检查当前登录的用户，是否有权限执行这个操作、访问这份数据。比如“用户A只能删除自己的帖子”。
  • 参数校验：你发来的东西合规吗？
    • 不仅校验格式（手机号是不是11位），还要校验业务逻辑（这个商品库存是否充足？这个订单是否属于你？）。永远不要相信前端传来的任何数据！
  • 速率限制：你调用得太快了吗？
    • 对 API 进行限流，比如“同一个IP每分钟只能调用5次登录接口”，防止机器人暴力破解密码或滥用服务。
  • 签名与加密：
    • 对关键请求（如支付）使用数字签名，确保数据在传输途中未被篡改。
    • 全程使用 HTTPS，防止请求在传输过程中被窃听。

终极结论：
API 就像你家房子的门。 前端 App 是正大光明从门进来的客人。但攻击者会尝试撬锁、翻窗、伪造钥匙，甚至用攻城锤撞门。后端安全工程师的工作，就是安装最坚固的门锁、设置警报系统、在屋内每个房间门口再加一道安检，确保无论请求从哪里、以何种方式过来，非法者都无法得逞。

是的，攻击者不仅可以轻易“跨过前端”伪造调用，这本身就是网络安全攻防的主战场。 一个健壮的 API 后端，必须假定所有来自前端的请求都可能是恶意的，并在此基础上进行层层验证。

主要漏洞类型学习

1.SQL注入

2.RCE远程代码执行

3.文件上传漏洞

4.文件包含漏洞

包含敏感文件

Linux：

在这里插入图片描述


Windows：

在这里插入图片描述
包含上传文件漏洞利用条件：

1.上传路径知晓
2.可执行有权限
3.有文件包含漏洞

包含日志

核心原理正是“利用已知路径，通过访问行为写入恶意代码，再包含执行”。

5.XSS

反射型XSS

检验是否存在：
出现弹窗，说明代码被执行了，漏洞是存在的

在这里插入图片描述


还可以获得网页cookie

在这里插入图片描述
存储型XSS

永久性，常见于留言框，评论等实现保存+展示的地方。
无需用户访问包含恶意代码的URL。
XSS钓鱼， XSS挂码， XSS蠕虫
比前面的漏洞危害更大
也可以用反射型的方式测试，也会有弹窗，而且是永久性的，哪怕刷新也会继续弹出
会发现JavaScript已经作为页面源代码插入与执行

在这里插入图片描述
特征存储型XSS反射型XSS
存储位置服务器数据库不存储，在URL中
触发条件访问被污染页面必须点击恶意链接
持久性永久（直到管理员删除）一次性（关闭页面即失效）
攻击场景留言板、评论、用户资料搜索框、错误页面、URL参数
危害等级⭐⭐⭐⭐⭐⭐⭐⭐

6.暴力破解

利用burpsuite抓包，send to intruder，导入字典，即可暴力破解

7.业务逻辑漏洞

短信验证码暴力破解
短信轰炸

8.权限绕过漏洞

未授权访问

基于数据库，web应用

水平越权

攻击者和受害者权限级别相同，攻击者通过修改参数等手段，访问受害者资料

垂直越权

攻击者和受害者权限级别不同，分为常见的向上越权（admin）和向下越权

9.CSRF（跨站请求伪造）

以dvwa这道题为例。先抓包，了解到是通过GET传参更改的password
GET /vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change


在存储型xss处抓包，改包，由于cookie一样，虽然是不同的站点，仍然可以实现更改密码操作
这是错误演示，因为xss仍然要求通过post传参，不能直接更改，而是要用它能接受的方式（同前面xss测试）传参

在这里插入图片描述


正确的：
<img+src%3d"http%3a//127.0.0.1%3a42001/dvwa/vulnerabilities/csrf/%3fpassword_new%3dpassword1%26password_conf%3dpassword1%26Change%3dChange"+style%3d"display%3anone%3b"/>
可以发现发出去以后马上收到了另一个更改密码的包，这个是来自csrf的

在这里插入图片描述

10.SSRF

攻击者诱导服务器向内网/外部发送请求，可能用于

1️⃣探测内网信息
web服务
开放端口
2️⃣读取敏感文件

eg. ?url=file:///etc/passwd

CTF中web入门题型

PHP特性

强弱类型比较
科学计数法

缺陷函数

strcmp ；md5；hash（都是接收到数组就返回NULL）
is_numeric（自动转换，如404a转换成404）

信息泄露

注释（F12看）
robots.txt（防爬虫，但是有的时候暴露重要信息或路径）
js信息泄露（前端代码审计）
vim信息泄露，先下载，再用Linux系统命令
vim -r 文件名查看

在这里插入图片描述
变量覆盖

特征：$$
传参：GLOBALS，会输出所有变量

请求头

Cookie
X-Forwarded-For

响应头

CTF中web进阶题型

代码执行
1️⃣可以有字母

变量函数（$a,$b这样的可以传入参数如system cat ）

2️⃣不可以有字母（无长度限制）

异或或者自增，变量为$_（可以下划线作为变量名避免出现字母）

在这里插入图片描述


绕过0：用弱比较漏洞返回false
绕过A：利用数组的array的第一个字母
然后利用自增可以得到所有字母

在这里插入图片描述
2️⃣不可以有字母（有长度限制）

取反

在这里插入图片描述


原字符串：system
按每个字母转化成ASCII对于数字：[115, 121, 115, 116, 101, 109]
数组中每个数字写成二进制，然后按位取反[140,134,140,139,154,146]
十进制转化成十六进制，然后url编码

在这里插入图片描述
命令执行

与上面的比起来更直接，一般可以直接获得flag

管道符（熟悉Linux操作）

；和& 两个都执行，不管前面的真假
| 直接执行后面的
|| 逻辑或，前假才后
&& 逻辑与，前假后不执行
%0a换行

空格绕过
关键字绕过

拼接，通配符*，？， 分割\

文件读取（指定内容）

方法一：?file=data://text/plain,aaa（传入文本内容aaa）
方法二：?file=php://input 通过抓包POST传参

文件包含
1️⃣远程文件包含

需 allow_url_include=On(PHP 配置)
包含远程 URL​ (如 http://attacker.com/evil.txt)

2️⃣本地文件包含
在这里插入图片描述


目录遍历
已上传（图片马、日志等）

文件上传
sql

Read more

前端与 Spring Boot 后端无感 Token 刷新 - 从原理到全栈实践

前端与 Spring Boot 后端无感 Token 刷新 - 从原理到全栈实践

🌷 古之立大事者，不惟有超世之才，亦必有坚忍不拔之志 🎐 个人CSND主页——Micro麦可乐的博客 🐥《Docker实操教程》专栏以最新的Centos版本为基础进行Docker实操教程，入门到实战 🌺《RabbitMQ》专栏19年编写主要介绍使用JAVA开发RabbitMQ的系列教程，从基础知识到项目实战 🌸《设计模式》专栏以实际的生活场景为案例进行讲解，让大家对设计模式有一个更清晰的理解 🌛《开源项目》本专栏主要介绍目前热门的开源项目，带大家快速了解并轻松上手使用 🍎 《前端技术》专栏以实战为主介绍日常开发中前端应用的一些功能以及技巧，均附有完整的代码示例 ✨《开发技巧》本专栏包含了各种系统的设计原理以及注意事项，并分享一些日常开发的功能小技巧 💕《Jenkins实战》专栏主要介绍Jenkins+Docker的实战教程，让你快速掌握项目CI/CD，是2024年最新的实战教程 🌞《Spring Boot》专栏主要介绍我们日常工作项目中经常应用到的功能以及技巧，代码样例完整 👍《Spring Security》专栏中我们将逐步深入Spring Security的各个
服务端之NestJS接口响应message编写规范详解、写给前后端都舒服的接口、API提示信息标准化

服务端之NestJS接口响应message编写规范详解、写给前后端都舒服的接口、API提示信息标准化

MENU * 前言 * 定义 * 提示信息设计原则 * 提示信息风格分类 * 提示信息模板化设计 * 国际化与多语言支持 * 最佳实践 * 参考示例（NestJS响应） * 总结 * 统一风格示例清单推荐 * API响应message清单（可直接使用） 前言 在现代后端开发中，接口响应不仅仅是数据的传递，还承担着向前端或用户传递操作状态和结果的功能。一个规范、统一的message字段设计，可以显著提升系统的可维护性、前端开发效率和用户体验。 定义 响应结构示例（NestJS风格） 各字段作用 提示信息设计原则 简洁明了 1、不宜过长，一般3~12个汉字。 2、避免含糊不清的词，如“完成了”、“OK”等。 统一风格 1、同一项目接口建议使用统一动词+状态组合，例如：获取数据成功、数据加载完成。 上下文清晰 1、提示信息应体现操作对象或类型，如“用户列表获取成功”
从 XMLHttpRequest 到 Fetch API：现代前端网络请求的演进与迁移指南

从 XMLHttpRequest 到 Fetch API：现代前端网络请求的演进与迁移指南

🧑 博主简介：ZEEKLOG博客专家，历代文学网（PC端可以访问：https://literature.sinhy.com/#/?__c=1000，移动端可关注公众号 “ 心海云图 ” 微信小程序搜索“历代文学”）总架构师，16年工作经验，精通Java编程，高并发设计，分布式系统架构设计，Springboot和微服务，熟悉Linux，ESXI虚拟化以及云原生Docker和K8s，热衷于探索科技的边界，并将理论知识转化为实际应用。保持对新技术的好奇心，乐于分享所学，希望通过我的实践经历和见解，启发他人的创新思维。在这里，我希望能与志同道合的朋友交流探讨，共同进步，一起在技术的世界里不断学习成长。 🤝商务合作：请搜索或扫码关注微信公众号 “ 心海云图 ” 从 XMLHttpRequest 到 Fetch API：现代前端网络请求的演进与迁移指南 引言：为什么我们需要新的网络请求方案？ 在前端开发领域，XMLHttpRequest (XHR) 长期统治着浏览器端的网络请求。然而，随着 Web

ESP32-S3驱动ILI9341液晶屏：显存清零、背光控制与RGB565显示原理

1. ESP32-S3 驱动 ILI9341 液晶屏的核心原理与工程实现 在嵌入式图形界面开发中，液晶屏驱动绝非简单的“初始化+显示”两步操作。尤其对于 ESP32-S3 这类集成 LCD 接口但需深度协同硬件资源的 SoC，其本质是 时序控制、内存管理与外设协同的系统工程 。本节将从底层硬件特性出发，解析 ILI9341 屏幕在 ESP32-S3 上的完整驱动逻辑，重点解决初始化后“花屏”、背光不亮、图片显示异常等典型问题。 1.1 花屏现象的本质：未清除显存与未配置显示内容 当完成 ILI9341 的寄存器初始化序列（如 LCD_Init() ）后，屏幕呈现杂乱无章的“花屏”，这是最普遍也最容易被误解的现象。其根本原因并非驱动代码错误，而是 显存（GRAM）处于未定义状态 。 ILI9341 内部显存是一块连续的