WEB 学习框架搭建

WEB 学习框架搭建

WEB 学习框架搭建

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

web应用框架

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

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


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

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

  1. 构建界面:画出登录页面,有手机号输入框、密码输入框和“登录”按钮。
  2. 监听事件:用户点击“登录”按钮时,前端代码被触发。
  3. 收集与校验:前端获取输入框里的手机号和密码,先做基本校验(如手机号格式、密码非空)。
  4. 调用API(最关键一步):** 前端使用 axiosfetch 等工具,发送这个请求。这个动作就叫 “调用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

AI Agent Skill Day 12:Web Search技能:互联网搜索与信息聚合

【AI Agent Skill Day 12】Web Search技能:互联网搜索与信息聚合 在“AI Agent Skill技能开发实战”系列的第12天,我们聚焦于Web Search技能——这一使Agent具备实时获取互联网公开信息能力的核心模块。随着大模型知识存在时效性限制(如训练数据截止至2023年或2024年),仅依赖内部知识库难以应对动态世界中的最新事件、股价、新闻、产品发布等需求。Web Search技能通过集成搜索引擎API(如SerpAPI、Google Programmable Search Engine、DuckDuckGo等),实现对网络信息的精准检索、结果聚合与语义提炼,是构建“活Agent”的关键一环。本技能广泛应用于智能客服、市场情报分析、科研辅助、金融舆情监控等场景,显著提升Agent的信息鲜度与决策质量。 技能概述 Web Search技能是指AI Agent在接收到用户查询后,自动调用外部搜索引擎接口,获取相关网页摘要、链接及结构化信息,并将结果进行清洗、去重、排序和语义压缩后返回给大模型,

StructBERT WebUI定制开发:情感分析交互界面实战

StructBERT WebUI定制开发:情感分析交互界面实战 1. 背景与需求:中文情感分析的工程落地挑战 在自然语言处理(NLP)的实际应用中,中文情感分析是企业级AI服务中最常见的需求之一。无论是电商平台的用户评论、社交媒体舆情监控,还是客服系统的自动响应,都需要快速准确地识别文本中的情绪倾向——正面或负面。 然而,在真实项目中,我们常面临以下问题: - 预训练模型部署复杂,依赖冲突频发 - 缺乏直观的交互界面,难以供非技术人员使用 - GPU资源依赖高,CPU环境下推理效率低下 - API接口不标准,难与前端系统集成 为解决这些问题,本文将带你深入一个基于 StructBERT 中文情感分类模型 的轻量级服务化实践案例,重点讲解如何通过 WebUI + REST API 双模式设计,实现开箱即用的情感分析系统。 2. 技术选型与架构设计 2.1 为什么选择 StructBERT? StructBERT 是阿里云 ModelScope

个性化图书推荐系统信息管理系统源码-SpringBoot后端+Vue前端+MySQL【可直接运行】

个性化图书推荐系统信息管理系统源码-SpringBoot后端+Vue前端+MySQL【可直接运行】

摘要 随着数字化阅读的普及,个性化图书推荐系统在提升用户体验和满足读者需求方面发挥了重要作用。传统的图书推荐方式往往基于简单的分类或热门榜单,难以满足读者多样化的兴趣偏好。现代推荐系统通过分析用户行为数据、阅读历史和偏好,能够提供更加精准的个性化推荐。本研究旨在开发一个基于SpringBoot后端、Vue前端和MySQL数据库的个性化图书推荐系统,该系统能够通过算法分析用户行为,动态调整推荐内容,从而提升用户的阅读体验和满意度。关键词:个性化推荐、数字化阅读、用户行为分析、动态调整、阅读体验。 本研究采用SpringBoot作为后端框架,结合Vue.js前端技术,构建了一个高效、可扩展的个性化图书推荐系统。系统通过MySQL数据库存储用户数据、图书信息和推荐记录,并利用协同过滤算法和内容-based算法实现精准推荐。功能模块包括用户注册与登录、图书浏览与搜索、推荐列表生成、用户反馈收集等。系统支持管理员对图书信息进行管理,同时提供用户个人中心,方便查看阅读历史和推荐记录。后端采用RESTful API设计,前端通过Axios实现数据交互,确保系统的高效运行和良好的用户体验。关键词:

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案 前言:为什么选择 LazyLLM 构建多 Agent 大模型应用? LazyLLM 作为低代码构建多 Agent 大模型应用的开发工具,可大幅降低大模型应用的开发与部署门槛。本文聚焦其在豆包模型的落地实践,将从源码部署豆包文本模型的完整配置步骤入手,延伸至官方 WebModule 启动可视化 Web 界面的实操流程,并配套精准性、简洁度等多维度的部署测试说明,为开发者提供可直接对照的实操指南,助力高效完成豆包模型在 LazyLLM 框架下的部署与验证。 LazyLLM 整体架构解析:三层联动的多 Agent 运行体系 LazyLLM 的架构分为三层级递进结构,各层级分工明确且联动协同,实现从应用开发到落地执行的全流程覆盖:上层(LazyPlatform AI 大模型应用开发平台):核心含应用编排平台以可视化编排、发布、回流、调优的闭环完成应用构建迭代与平台管理模块通过租户、权限管理支撑多用户运维,是开发者的高效开发管理入口中层(