企业官网建设流程全解析

功能型网站开发,影响网站pr的主要因素有哪些,洛阳市网站建设,包头网站建设熊掌号一、XSS#xff08;跨站脚本漏洞#xff09;1、反射型-xss#xff08;get#xff09;1、1测试过程首先确认页面是否存在XSS漏洞#xff0c;在对应的输入点输入一些特殊的字符例如#xff1a;’”123等#xff0c;目的是检测我们的输入是否会被过滤掉#xff0c…一、XSS跨站脚本漏洞1、反射型-xssget1、1测试过程首先确认页面是否存在XSS漏洞在对应的输入点输入一些特殊的字符例如’”123等目的是检测我们的输入是否会被过滤掉再验证输出是否可以输出输出了who is ‘”123,i don’t care!查看页面的源代码F12开发者模式我们可以看到我们输入的一些特殊字符都被原封不动的输出到了这里意味着我们输入一些JavaScript代码也可以原封不动的输出我们构造一个简单的payload输入scriptalert(‘XSS’)/script我们发现输入到后面输入不进去了说明我们的输入长度被限制了我们打开开发者工具设定了一个最大输入长度为20我们修改为200之后就可以正常输入了我们提交之后发现我们输入的JavaScript代码成功在浏览器里面执行了反射型的XSS与存储型不同是没有被存储到后台的我们一刷新页面这个弹窗也就没了刷新之前的源码如下刷新之后的源码如下get型的xss我们可以查看到对应数据会显示在url中意味着我们可以利用这种get型的xss在一些网站对应的页面构造一些JavaScript代码如果有用户点击了这个url就会执行这个payload4、这样我们的反射型-XSS漏洞就测试成功了1、2漏洞成因先接受GET参数submit和message如果message是空的设置$html为提示文本如果message为kobe则拼接$_GET[‘message’]的html内容如果message是其他的内容则拼接另一段html内容最终$html内容会被输出到页面。整个的代码没有做过滤操作没有做防XSS的操作直接将用户可控的$_GET[message]未经转义地插入到$html中当$html被输出到页面时浏览器会将其中的恶意 HTML/JS 代码解析并执行。1、3防范策略分析把用户输入的「危险特殊字符」比如、、、转换成浏览器只认 “文本”、不认 “代码” 的格式HTML 实体让恶意的 HTML/JS 代码无法被解析执行。原本浏览器看到script会认为是 “执行 JS 代码”经过这个函数处理后script会变成script浏览器只会显示成普通文字script不会执行任何代码。对$_GET[message]用htmlspecialchars()转义后再拼接2、反射型-xsspost2、1测试过程需要我们输入账号和密码我们可以试一下之前暴力破解表单得到的账户和密码admin/123456或者点一下提示得到账户密码登录成功后我们看到一个输入点我们输入一些特殊的字符例如’”222等目的是检测我们的输入是否会被过滤掉再验证输出是否可以输出发现输出了who is ‘”222,i don’t care!这与上一个反射型-xssget是一样的那么接下来的步骤也一样的构造payload输入值得注意的是这一关没有限制我们的输入长度scriptalert(xss)/script输出弹窗我们的测试就成功了get型提交的数据会显示在url中而post不会攻击者自己搭建一个第三方网页这个网页中包含一个隐藏的表单Form表单的 action属性指向存在 XSS 漏洞的 URL。 1.首先找到存在xss漏洞的参数。例如http://127.0.0.1/pikachu/vul/xss/xsspost/xss_reflected_post.php 的 message 参数存在 xss 漏洞当你 POST messagescriptalert(1)/script时页面会弹窗2.在一个你控制的攻击者服务器上如 http://example.com创建一个 HTML 文件例如 payload.html。3. 在该 HTML 文件中编写一个自动提交的隐藏表单。4. 诱骗被攻击者点击链接http://example.com/payload.html5. 被攻击者点击链接访问 payload.html 。 浏览器加载页面其中的 JavaScript 会自动提交隐藏的表单。 浏览器会向 http://127.0.0.1/pikachu/vul/xss/xsspost/xss_reflected_post.php 发送一个POST 请求Body 中包含恶意的 message 参数。 目标网站处理这个请求并将恶意脚本返回给被攻击者的浏览器。 被攻击者的浏览器执行该脚本XSS 攻击完成。2、2漏洞成因直接将用户通过 POST 提交的$_POST[message]未做任何转义处理原样拼接到$html字符串中当$html最终输出到页面时若用户输入恶意 HTML/JS 代码如scriptalert(document.cookie)/script浏览器会解析并执行该代码导致会话窃取、页面劫持等风险。2、3防范策略分析对$_POST[message]使用htmlspecialchars()进行 HTML 实体转义阻断恶意代码3、存储型-xss3、1测试过程我们在留言板上随意留言我们的留言会被存储在这个页面上刷新页面也还在那么我们的留言被后台存储下来了按照思路来测试这个留言板是否存在xss漏洞先输入一些特殊字符我们输入的东西被当作留言直接显示出来了查看页面的源码我们输入的一些特殊字符和正常的数字都被输出到了p这个标签中与反射型-xss差不多没有做任何的过滤和转移处理输入构造的payload去测试scriptalert(xss)/script意味着我们提交的被存储到后台了即使我们刷新依然会出现这个弹窗每次我们访问这个页面都会出现这个弹窗我们的测试就成功了3、2漏洞成因留言内容$_POST[message]存入数据库前仅做了防 SQL 注入的escape转义但从数据库取出$data[content]后直接通过echo $data[content]输出到页面未做 HTML 实体转义。若用户输入恶意代码如scriptalert(document.cookie)/script代码会被存储到数据库后续所有访问留言板的用户加载页面时浏览器会执行该恶意代码。3、3防范策略分析在展示内容时对数据库取出的$data[content]做 HTML 实体转义4、Dom型-xss4、1测试过程dom型就是在网页的前端直接进行的并不会到像反射型一样提交到后台后再传输回来而是直接在前端完成的操作随意输入字符查看源码用了dom里面的getElementById来获取id为text标签的内容也就是下面input也就是我们输入的内容把我们输入的内容赋值给str这个变量又把我们输入的内容又写到了通过这个字符串拼接的方式写到了a标签的href属性里面这个a标签会被写到id等于dom的一个div标签里面我们复制innerHTML后面的来构造一个payload构造payload来测试! onclickalert(xss)当我们点击这个what do you see就会出现一个弹窗说明我们的测试成功了存在一个dom型的xss漏洞4、2漏洞成因按钮点击触发domxss()函数获取text输入框的值str将str直接拼接到a hrefstrwhat do you see?/a中通过innerHTML插入到iddom的 div 内若用户输入恶意内容如img srcx onmouseoveralert(xss)innerHTML会将其解析为 HTML 元素触发onmouseover等事件执行恶意 JS 代码。4、3防范方案分析DM API 创建元素通过document.createElement创建a标签避免拼接 HTML 字符串从根源阻断恶意代码注入href属性安全设置直接赋值aTag.href str时浏览器会自动对str中的危险字符做转义如javascript:协议的内容会被标记为不安全部分环境下不会执行textContent渲染文本aTag.textContent仅将内容作为纯文本显示不会解析 HTML/JS 代码。5、Dom型-xssx5、1测试过程随意输入一些内容然后查看源码定义了一个function功能通过url来获取我们输入的内容然后赋值给了一个xss利用dom的方法写入到a标签里面那么就跟反射型xss很像我们用上一个构造的payload进行测试输入payload! onclickalert(xss)当我们输入payload之后依次点击那两句话就会出现弹窗说明成功了这个也上一个dom的区别在于输入是从url里面获取的如果是需要攻击只需要把url发给被攻击者点开链接后就会受到攻击5、2漏洞成因用户可控的 URL 参数text被直接处理后通过innerHTML拼接为 HTML 内容插入页面未做任何安全过滤攻击者可构造恶意text参数如img srcx onmouseoveralert(xss)触发恶意 JS 代码执行5、3防范策略分析DOM API 创建元素通过document.createElement生成a标签避免 HTML 字符串拼接setAttribute设置属性href属性通过setAttribute赋值浏览器会自动转义危险内容如javascript:协议的恶意代码6、xss之盲打6、1测试过程只有后台可以看到前端的输入内容前端无法判断是否有xss漏洞存在我们随意输入一些内容查看输入后的结果可以看到我们输入的内容并没有输出到前端来可能是只有管理员可以在后台查看我们输入的内容如果我们输入的内容是我们制作的payload的是不是管理员的页面就被插入了恶意脚本我们试一下我们在前端输入我们构造的payloadscriptalert(xss)/script然后点击提示登录管理员界面可以看到我们关管理员界面被插入了脚本对于攻击者是一种尝试的行为并不知道后台有没有输出输出有没有过滤与我们存储型xss有一些类似都存储到了后端这样我们就测试成功了6、2漏洞成因输入未处理用户通过表单提交的content内容、name姓名会被直接存入数据库未做任何安全过滤输出未转义后台展示数据时直接将数据库中的$data[content]$data[name]原样输出到页面如td{$data[content]}/td。若用户在content/name中输入恶意代码会被存储到数据库后台管理员访问展示页面时浏览器会执行该恶意代码导致会话窃取、页面劫持等风险。6、3防范策略分析将content/name/id中的特殊字符如、、、转为 HTML 实体如→确保浏览器仅将其识别为纯文本阻断恶意代码执行7、xss之过滤7、1测试过程前端限制绕过直接抓包重放或者修改前端代码大小写输入比如SCRIPTaLerT(111)/sCrIpt拼凑例如scriscriptptalert(111)/scri/scriptpt或者使用注释进行干扰scri!--test--ptalert(111)/sc!--test--ript随意输入一些内容然后我们查看源码可以看到我们输入的script被过滤掉了那我们可以尝试其他的方式输入payload输入测试payload使用大小写混合的方式出现弹窗说明我们构造的payload成功绕过了过滤测试成功7、2漏洞成因通过preg_replace过滤script标签但正则规则无法覆盖所有 XSS 触发场景如大小写变形的Script、拆分的scrscriptipt或非script标签的 XSS 方式如img srcx onerroralert(1)处理后的$message直接拼接到$html中未做 HTML 实体转义即使过滤了script攻击者仍可通过其他标签 / 事件如onmouseover注入恶意代码。7、3防范策略分析htmlspecialchars转义将$_GET[message]中的所有特殊字符如、、、转为 HTML 实体无论攻击者输入何种恶意内容浏览器都会将其识别为纯文本彻底阻断 XSS 代码执行8、xss之htmlspecialchars8、1测试过程按照思路我们随意输入一些内容提交然后查看源码我们可以看到我们输入的一些特殊字符被转译成了别的字符但是我们发现单引号没有被编码那么可以猜想后端是使用默认的htmlspecialchars进行的编码我们构造payload进行测试输入payload因为单引号没有被编码我们可以构造使用单引号的payload点击提交的内容就会出现弹窗说明我们的测试成功了htmlspecialchars 的设计目标是防止特殊字符被浏览器解析比如避免被识别为标签开始。但当转义后的内容出现在如事件属性 onclick、script标签内时浏览器会经历 “两步解析”HTML 解析阶段htmlspecialchars 转换的实体如 会被还原为原始字符。JavaScript 解析阶段:还原后的字符如 会被当作 JavaScript 语法的一部分解析从而触发代码执行。所以单单使用 htmlspecialchars 转义是不够的还需要 Javascript 转义等多种转义的配合。8、2漏洞成因转义不彻底htmlspecialchars($_GET[message])默认仅转义双引号参数为ENT_COMPAT不转义单引号上下文不匹配当$message被插入到input标签的value属性如value{$message}时未转义的单引号可被用来闭合属性注入恶意事件如输入 onclickalert(1)当$message被插入到a标签的href属性时若输入javascript:alert(1)即使转义了引号仍可能触发 JS 执行部分场景下。8、3防范策略分析ENT_QUOTES参数让htmlspecialchars同时转义单引号和双引号避免属性闭合的风险上下文适配对于input的value属性转义后的内容可安全填充对于a标签的href若内容是 URL需先通过urlencode处理再做 HTML 转义防止javascript:协议的恶意注入9、xss之herf输出9、1测试过程随意输入一些内容然后查看源码可以看到可以看到这里 htmlspecialchars 连单引号也进行转义了但是并不是就这样安全了在 href 属性中可以通过 javascript 协议来执行 js构造payload输入9、2漏洞成因仅对$message做了 HTML 转义但未限制 URL 协议若用户输入javascript:alert(‘xss’)href会被填充为该危险协议会执行恶意 JS 代码9、3防范策略分析通过parse_url解析 URL仅允许http/https协议阻断javascript等危险协议的注入10、xss之js输出10、1测试过程随意输入一些内容查看源码构造payload测试通过网页源码构造闭合p’/script scriptalert(“xss”)/script10、2漏洞成因PHP 将用户可控的$_GET[message]直接输出到 JavaScript 代码中未做js上下文的转义处理。若用户输入恶意内容如tmac;alert(1);//会被拼接为合法的js代码执行时触发恶意js10、3防范策略分析这里如果进行html的实体编码,虽然可以解决XSS的问题,但是实体编码后的内容,在JS里面不会进行翻译,这样会导致前端的功能无法使用。所以在JS的输出点应该使用\对特殊字符进行转义。总的来说xss的漏洞防范原则就是输入做过滤输出做转义二、CSRF1、CSRFget1、1测试过程首先登录页面对住址进行修改过程中打开bp抓包查看bp抓包内容GET/vul/csrf/csrfget/csrf_get_edit.php?sexboyphonenum15988767673addLAemailkobe%40pikachu.comsubmitsubmitGet请求向后台发送了这些数据我们在这里没有看到CSRF的Token也就是说后台没有做防CSRF的措施让被攻击者点击攻击者伪造的链接http://127.0.0.1/vul/csrf/csrfget/csrf_get_edit.php?sexboyphonenum15988767673addGuilinemailkobe%40pikachu.comsubmitsubmit保证kobe在登录状态下点击了这个攻击者发送给他的链接kobe的地址就被改了1、2漏洞成因修改会员信息的请求使用GET方法提交且未验证 CSRF 令牌攻击者可构造包含恶意参数如sex、phonenum的 URL诱导已登录用户访问用户会在不知情的情况下被修改会员信息如手机号、地址等1、3防范策略分析通过随机令牌验证请求的合法性阻断攻击者构造的恶意请求例如Token2、CSRFpost2、1测试过程在这里请求是以post方式提交抓包到右键发送到repeater构造poc打开刚才访问网站的浏览器注意不能关闭原来登录网站的TAB页面此时也不能关闭代理创建一个文档存放在csrf的目录下用浏览器打开点击submit之后信息就被修改了2、2漏洞成因没有Token攻击者可构造恶意表单诱骗已登录用户提交篡改用户信息2、3防范策略分析补充CSRF的Token防止攻击者构造恶意表单来进行攻击3、CSRFtoken3、1测试过程其他操作与之前一样先登录然后修改信息bp抓包GET/vul/csrf/csrftoken/token_get_edit.php?sexgirlphonenum12345678922addguilinemaillucy%40pikachu.comtoken72652694e5a6ca0bfd822326803submitsubmit其他部分的请求与get的差不多但是多了一个token我们看一下源码每次点击修改信息会把数据提交到后台每当打开这个页面的时候去访问了edit.php文件生成一个token把这个token发到前端每当提交数据后台会对这个token进行验证只有对上了这个数据才会成功修改每次的token都不一样会生成一个 token并与 session 绑定后端生成 token每次页面刷新 token 值也会刷新并输出到前端前端每次提交请求并提交 token 值到后端进行验证。即使攻击者可以轻松伪造 GET 请求但是攻击者得到的 token 值和被攻击者的 token 值不一样就无法伪造有效的 GET 请求。3、2漏洞成因敏感数据通过 GET 方法传递会暴露在 URL 中易被泄露或窃取3、3防范策略分析将请求方法改为 POST避免敏感数据暴露在 URL 中三、总结XSS 方面不管是存储型输入存后台所有人看都触发、反射型仅当前页面有效刷新就没还是 DOM 型前端直接处理本质都是输入的恶意代码没被过滤直接在页面执行了。我用特殊字符测是否过滤再构造脚本弹窗验证还试过大小写混合、拆分标签绕过过滤最后用转义特殊字符的方法防御。CSRF 则是利用用户已登录的状态伪造链接或隐藏表单诱骗用户点击就篡改信息。GET 型直接改 URL 参数POST 型用表单自动提交加了 Token 验证后就防住了但要注意敏感数据别用 GET 传容易泄露。整体下来漏洞大多是因为代码没过滤输入、没转义输出防御关键就是 “输入过滤、输出转义”再给敏感操作加 Token 验证这样就能挡住大部分攻击了。