跨站点端口攻击 – XSPA(SSPA)

许多Web应用程序提供的功能将数据从其他Web服务器,由于种种原因。下载XML提要,从远程服务器,Web应用程序可以使用用户指定的URL,获取图像,此功能可能会被滥用,使制作的查询使用易受攻击的Web应用程序作为代理运行在远程攻击其他服务的基于文本的文件等。 /本地服务器。通过这种滥用而产生的功能被命名为攻击,跨站点端口的攻击(XSPA)。

XSPA(SSPA)是什么?

如果应用程序处理用户提供的URL和不验证/消毒后端从远程服务器接收到响应,然后将其发送回客户端应用程序是容易受到跨站点端口的攻击。攻击者可以通过发送特制的查询到一个易受攻击的Web应用程序代理攻击,面临的外部Internet服务器,内网设备和Web服务器本身易受攻击的Web应用程序使用的广告功能。的反应,在某些情况下,可以进行研究,以确定服务的可用性(端口状态,横幅等),甚至在非传统的方式获取数据的远程服务。

PHP fsockopen() function:

<?php

function GetFile($host,$port,$link)

{ www.2cto.com

$fp = fsockopen($host, intval($port), $errno, $errstr, 30);

if (!$fp) {

echo “$errstr (error number $errno) \n”;

} else {

$out = “GET $link HTTP/1.1\r\n”;

$out .= “Host: $host\r\n”;

$out .= “Connection: Close\r\n\r\n”;

$out .= “\r\n”;

fwrite($fp, $out);

$contents=”;

while (!feof($fp)) {

$contents.= fgets($fp, 1024);

}

fclose($fp);

return $contents;

}

}

?>

此实现获取数据,如由一个用户使用的fsockopen PHP函数(任何文件或HTML)请求。此功能建立一个TCP连接的套接字的服务器上,并进行原始数据传输。

PHP curl_exec() function:

<?php

if (isset($_POST[‘url‘]))

{

$link = $_POST[‘url‘];

$curlobj = curl_init();

curl_setopt($curlobj, CURLOPT_POST, 0);

curl_setopt($curlobj,CURLOPT_URL,$link);

curl_setopt($curlobj, CURLOPT_RETURNTRANSFER, 1);

$result=curl_exec($curlobj);

curl_close($curlobj);

$filename = ‘./curled/’.rand().’.txt’;

file_put_contents($filename, $result);

echo $result;

}

?>

这是另一种非常常见的实现,通过PHP使用curl获取数据。“卷曲”文件夹下的文件/数据下载并存储到磁盘,并附加一个随机数“。txt’结尾的文件扩展名。

在本系列的下一部分,我们将看到一些可以启动的攻击使用此vulnerbility。XSPA允许攻击者在目标服务器基础设施,主要是内网的Web服务器,Web服务器本身,以及面向互联网的服务器以及。目前,我已经遇到以下五种不同的攻击方式,可以启动使用XSPA:

1。端口扫描远程互联网服务器,内网设备和本地Web服务器本身。横幅敛也有可能在某些情况下,

2。开发弱势运行的程序在Intranet或本地Web服务器

3。攻击内部/外部Web应用程序很容易通过URL来获取参数的漏洞(SQLI,参数操作等)

4。指纹图谱的Intranet Web应用程序使用标准的应用程序的默认文件及行为

5。阅读使用file :/ / /协议处理程序的本地Web服务器上的文件。

时间: 2024-10-19 16:54:27

跨站点端口攻击 – XSPA(SSPA)的相关文章

【安全编码实践】保护自己免受跨站点脚本攻击

声明:本文由Bypass整理并翻译,仅用于安全研究和学习之用. 文章来源:https://medium.com/bugbountywriteup/how-to-write-secure-code-b2757b59cd4b 如何编写安全代码?保护自己免受跨站点脚本攻击! 过去几个月我一直致力于安全代码实践,我一直在努力与社区讨论易于采用的方法.我们每天看到的不安全代码的数量确实令人震惊,我们都同意“预防胜于治疗”. 保持我们的代码和应用程??序安全的最佳方法是从一开始就正确编程.编写安全代码并不困

RailsCase27 Cross Site Scripting 跨站点脚本攻击

跨站点脚本是开发过程中经常需要考虑的安全问题.此种情形发生在允许用户直接输入html.javascript脚本时.在下述的website中,我们并没有过滤输入的内容,导致一些安全漏洞. 如果在输入框中输入由<script>包围的内容,当页面被加载的时候,脚本将被执行,每次均将在前端展示.例如,如果输入<script>alert('hello')</script>并保存,每次浏览此页面时,都将看到alert的窗口. 嵌入页面的javascript脚本如下: termina

跨站点脚本攻击(XSS)

XSS分类: (1)反射型XSS:只是简单地把用户输入的数据反射给浏览器.往往需要诱使用户"点击"一个恶意链接.也叫"非持久型XSS" (2)存储型XSS:把用户输入的数据"存储"在服务器端.也叫"持久型XSS" (3)DOM Based XSS:从效果上来说也是反射型XSS,通过修改页面的DOM结点形成的XSS. 1.cookie劫持:httponly或者将cookie和客户端IP绑定可防止 2.XSSPayload: (1

跨站点脚本攻击

介绍 XSS是跨站脚本攻击(Cross Site Scripting)的缩写.XSS是因为有些恶意攻击者往Web页面中插入恶意Script代码,当用户浏览该页面时,嵌入的Script代码将会被执行,从而达到恶意攻击用户的特殊目的. 条件 攻击者需要向web页面注入恶意代码: 这些恶意代码能够被浏览器成功的执行. 类型 XSS反射型攻击,恶意代码并没有保存在目标网站,通过引诱用户点击一个链接到目标网站的恶意链接来实施攻击的,攻击是一次性的. XSS存储型攻击,恶意代码被保存到目标网站的服务器中,这

我要学ASP.NET MVC 3.0(十三): MVC 3.0 防止跨站点请求伪造 (CSRF) 攻击

我要学ASP.NET MVC 3.0(十三): MVC 3.0 防止跨站点请求伪造 (CSRF) 攻击 概述      众所周知,ASP.Net MVC程序在浏览器运行时产生了标准的Html标签,包括浏览器要发送的关键数据等内容都在Html内容里面,听起来不错,但是假如我们仿造类似的Html内容,更改里面关键数据,在浏览器运行起来会怎么样呢?好下面我们就做这样一个例子.       CSRF攻击例子 首先我们拿以前做好的person/edit作为例子 先看控制器代码 //初始页面        

24Exchange Server 2010跨站点部署-公网发布443&25端口

12.3 TMG公网发布 12.3.1 发布443端口 TMG安装部署这里就不介绍,关于TMG发布Exchange有两种方式,一种就是桥接模式Bridge,一种就是隧道模式Tunnel,这里采用隧道模式,模拟传统的硬件防火墙,新建一条非Web服务器协议发布规则 输入规则名称 输入NLB群集的IP地址 点击新建 输入新建协议的名称 点击新建 定义一个入栈的443的TCP协议类型 点击下一步 否,点击下一步 点击完成 点击下一步 选择侦听外部IP地址 点击完成,完成规则创建 应用规则,TMG一般20

[不常用] - CSRF(跨站点请求伪造)

CSRF,Cross Site Request Forgery,即跨站点请求伪造.   这种攻击是指,在用户正常登录系统以后,攻击者诱使用户访问一些非法链接,以执行一些非法操作. 比如:如果删除用户操作(如,yourdomain.com/deluser?id=123)没有经过防范CSRF的处理,那么,假设用户登录系统后,攻击者诱使用户同时访问了攻击者的站点的一个链接(该链接正好为yourdomain.com/deluser?id=123),那么,系统就会在用户不知情的情况下丢失一个用户.    

基于Window Azure 静态网站的跨站点高可用!

?? 我们上篇文章讨论了基于PAAS的简单网页的Failover,由于相对操作比较简单,因为PAAS的接口对应给用户相对较少,因此针对无状态的配置相对简单.而针对通过虚拟机来配置我们可以实现本地高可用和跨站点高可用来结合提供更高的可用性. 而基于虚拟机方式提供的高可用,我们可以在本地建立两台虚拟机,保证我们应用访问的高可用,因为没有涉及到交互的静态页面,因此我们可以采用建立可用性群集的方式保证我们的网站在同一个数据中心的可用性.同时我们用Traffic Manager来保证我们在跨数据中心的时候

跨站点的请求(web)

恶意网站针对用户可能登陆的某个站点实施跨站点攻击,在用户不知情情况下,让用户做了某些非本意的操作. 一般情况,服务端对每个请求除了验证session,还应对除特殊几个请求外的其它请求都验证请求中唯一标识.一般使用服务端返回的jsessionId放在请求中. 这个jsessionId存在于客户端浏览器的内存中,不知恶意网站js是否可以获取用户正在访问应用的这个jsessionId,若是可以,那不是恶意链接可以动态拼接这个jsessionId了,服务器还是会受到攻击.