这个JavaEE不知道出了什么问题，配置也配置不好，先这样吧。

32∽40做不了实验先不看了，回去调试，从41开始。

ASP

这个数据库的名字就是自己所有的数据都存在哪个数据库中，放在本地MySQL下面，根据数据用户名和密码识别哪个数据库。

Axercise无连接，无需连接数据库，直接放在文件夹下面用一个路径连接，网站的目录下面。

有的人懒得改默认的名字与位置，所以一下就被找到了数据库的位置。

触发了win7的蓝屏漏洞。

短文件漏洞。

这里前面的就是缩写。

不知道为什么莫名其妙连不上，随便吧。

他这个是搞短文件爆破的吧，直接猜测文件名

IP配置好麻烦，直接看算了。

这个漏洞也好好玩，解析漏洞吧，有分号的时候直接自动把内容执行了。

感觉短文件漏洞本质上也是暴力破解，只不过只有暴力6个。

这就是注入

找后台，可以用短文件漏洞也可以扫描目录。

有1对1数据库管理有一对多数据库。

这运行一下就差不多会了，多一个少一个都会报错。

这个感觉是数据库的那个什么鬼联动而设计的代码。

本地的数据库的话，只有链接的时候才有用，其他的都是猜小数据库的名字

而access就直接全是表。

记录所有的数据库的表。

在这1block这个数据库下面的表。

他说的这个是每个连接数据库下自带的小数据库（默认固定的），里面存储的表。

.是指哪个大数据库下的表

不过这个得大于5.0版本。

是属于哪个数据库下的表

你看到的"分开也能执行"，核心是SQL注入拼接改变了原语句结构，且UNION联合查询的语法特性让拆分后的语句依然符合MySQL的执行规则，具体原因拆解如下：

一、核心：SQL注入的"语句拼接篡改"本质

你的PHP代码直接将 $id 拼接到SQL语句中：

php

$sql="select \* from demo01 where id=($ id)";

当你传入 id=1 union select 1,2,3,group_concat(table_name),5,6 from information_schema.tables where table_schema='demo01' 时，恶意参数会和原语句拼接成一个完整的、新的合法SQL语句：

sql

select * from demo01 where id=(1 union select 1,2,3,group_concat(table_name),5,6 from information_schema.tables where table_schema='demo01')

并不是"分开执行"，而是恶意参数把原单条查询，改造成了包含UNION的复合查询语句，MySQL会将其作为一个整体解析执行。

二、UNION查询的语法特性允许"拆分式拼接"

UNION联合查询的核心规则是前后两个查询的列数必须一致，你的注入语句刚好满足这个条件：

原查询 select * from demo01 返回的列数，和你注入的 select 1,2,3,group_concat(table_name),5,6 的列数匹配；
MySQL解析时，会将 () 内的 1 union select ... 视为一个子查询，只要子查询语法合法，就会和原查询合并执行，分别获取结果后再合并返回；
哪怕你把注入语句拆成多段（比如分多次传参、或语句分段书写），只要最终拼接后的完整语句符合UNION语法，MySQL就会执行。

三、"分开执行"的视觉错觉来源

你看到的"分开"，实际是：

原语句的部分： select * from demo01 where id=(1 ；
注入的部分： union select 1,2,3,group_concat(table_name),5,6 from information_schema.tables where table_schema='demo01') 。

这两部分拼接后形成了语法完整的复合查询，MySQL并不会把它们当作两个独立语句，而是按 () 的优先级先执行子查询，再执行外层查询，最终返回联合后的结果（也就是你看到的 admin,gbook,news ）。

简单说，不是"分开执行"，而是注入参数把原语句补全成了一个合法的复合SQL语句，UNION的语法规则又让这个复合语句能正常执行。

要不要我帮你分析如何通过预处理语句彻底阻断这种UNION注入，并写出对应的防护代码？

就是获取列明的信息必定列出来，然后在那里查询。