能力值：
( LV2，RANK：10 )
|
-
-
2 楼
占领沙发，~~
|
能力值：
( LV8，RANK：120 )
|
-
-
3 楼
重在参与
答错了，不要笑我
题目1. 在通过提交专门设计的输入探查一个应用程序中是否存在常见的漏洞时，应用程序频繁返回包含调试信息的详细错误消息。有时，这些消息与其他用户造成的错误有关。这种情况发生一次后，就无法令其再次发生。这表示应用程序存在什么逻辑缺陷？接下来你该如何处理？
内存不可读或溢出，用静态调试或动态调试处理一下。
题目2. 要针对应用程序的一项敏感功能实施 XSRF 攻击，必须满足什么前提条件？
一个Web应用程序主要依赖HTTPcookie 传送会话令牌
题目3. 哪三种防御措施可用于防止 JSON 劫持攻击？
1.应用程序应使用标准的反XSRF防御阻止跨域请求访问敏感数据。访问JSON对象的请求中应包含一个无法预测的参数，并且在返回数据前应对其进行确认。
2.当应用程序从它自己的域中获取JSON对象时，并不仅限于使用<script>标签包含这个对象。因为请求在站内执行，客户端代码可以使用XMLHttpRequest自由访问响应数据，并可在将其作为JavaScript解释前对它进行其他处理。这意味着，为防止JOSN劫持，应用程序可以在响应的开始部分插入无效或有问题的JavaScript，客户应用程序在处理脚本前将会删除这些内容。
3.由于应用程序可以使用XMLHttpRequest获取JSON数据，因此它也可以使用POST请求完成这项任务。如果应用程序仅接受使用POST访问JSON对象的请求，它就能够阻止第三方站点将这些请求包含在<script>标签内。
题目4. 假设受攻击的应用程序使用两台不同的服务器：一台应用程序服务器和一台数据库服务器。已经发现一个漏洞，可以在应用程序服务器上执行任意操作系统命令。那么如何利用这个漏洞获取保存在数据库中的敏感应用程序数据？
利用漏洞在在应用程序服务器执行任意操作系统命令，上传攻击工具，1.对数据库进行注入式攻击，获取数据库的数据2.将数据库下载后攻击。
也可以在该应用程序服务器上进行嗅探，分析应用程序服务器和数据库服务器之间的通信，可能发现用户名及密码，用该用户名密码，login应用程序。
尝试社会工程学方法分析。
题目5. Linux、Apache、MySQL 与 PHP 等体系架构组件常被发现安装在同一台物理服务器上。为何这样做会削弱应用程序体系架构的安全状况？
多种服务在一个服务器上，根据水桶原理，服务器的安全性是由服务中安全性最低的一个服务决定的。
题目6. 如果一个 Web 服务器允许通过 HTTP 与 HTTPS 访问它的功能，在查询漏洞时，使用这两个协议有何差别？
http的port是80，https是443两者端口不同
|
能力值：
( LV13，RANK：290 )
|
-
-
4 楼
封面真是。。。。
|
能力值：
( LV4，RANK：50 )
|
-
-
5 楼
答不出 买来看看
|
能力值：
( LV2，RANK：10 )
|
-
-
6 楼
静静地观望 
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
太多了，就光Shellcoder's handbook 就700多页，怎么也得1个月才能读完。。
|
能力值：
( LV2，RANK：10 )
|
-
-
8 楼
观望观望观望
|
能力值：
( LV9，RANK：270 )
|
-
-
9 楼
题目4. 假设受攻击的应用程序使用两台不同的服务器：一台应用程序服务器和一台数据库服务器。已经发现一个漏洞，可以在应用程序服务器上执行任意操作系统命令。那么如何利用这个漏洞获取保存在数据库中的敏感应用程序数据？
一、如果可以执行系统命令，查询其是否有写权限，如果可以，可以使用上传或写二进制文件的方法植入木马并运行，然后以应用程序服务器为跳板对数据库服务器进行渗透，方案一：直接渗透（主机端口扫描、操作系统漏洞探测、数据库安全扫描、应用程序漏洞探测等）。方案二：嗅探数据库通讯账户及密码，如果得到账户密码后不能直接远程连接数据库，可用应用程序服务器做跳板进行连接。
二、如没有写权限，则执行系统命令查看应用程序文件，挖掘程序缺陷。如获得账户密码配置信息；如是web应用程序，可篡改数据库查询语句（这里说的篡改不是直接改写web程序，因为没有写权限，我们说的篡改是通过sql注入等手段实现的，数据库查询），查询敏感信息，通过正常web程序界面的回显获得敏感信息。
题目5. Linux、Apache、MySQL 与 PHP 等体系架构组件常被发现安装在同一台物理服务器上。为何这样做会削弱应用程序体系架构的安全状况？
组件增加了，安全隐患也增加了，风险也累加了。违反传说中的“最小服务”原则。
题目6. 如果一个 Web 服务器允许通过 HTTP 与 HTTPS 访问它的功能，在查询漏洞时，使用这两个协议有何差别？
简单来说http未加密，https使用安全套接字层(SSL)进行信息交换并支持证书。
探测漏洞时候，如果是探测传输层面的缺陷，http可能存在明文传输，敏感信息被泄露的安全隐患。https在传输的时候数据是经过加密的，可在一定程度上起到防监听的作用。
如果是探测应用程序的缺陷，个人感觉没什么差别，因为http和https主要的区别在于对通信的加密和证书的认证，应用程序的缺陷探测，一般方法是提交测试代码，查看回显（如sql注入，xss等），是应用程序层面的探测，与通讯关系不大。
|
能力值：
( LV9，RANK：270 )
|
-
-
10 楼
题目3. 哪三种防御措施可用于防止 JSON 劫持攻击？
个人感觉主要方法的核心应该是：多输入的过滤和对输出的转译
对非法用户提交的URL进行过滤，阻截非法URL即可。
|
能力值：
( LV12，RANK：230 )
|
-
-
11 楼
Google了一下：：
1 缓冲区溢出，，可以将专门设计的输入逐渐减少，或者从应用程序频繁返回包含调试信息的详细错误消息中得到一些具体信息进行下一步的调试。
2 应用程序赖以管理会话的信息对浏览器的透明性问题。我们知道，为了提高Web应用的便利性，用来管理会话的信息，例如Cookie或者基于HTTP的身份验证（例如HTTP基本认证、非基于表单的认证）等敏感信息，都是由浏览器来存放的，并在每当向需要身份验证的应用程序发送请求时自动捎带上这些信息。也就是说，浏览器可以访问会话管理信息，如果Web应用程序完全依赖于这类信息来识别一个用户会话，这就为跨站请求伪造创造了条件。
3(1)应用程序应使用标准的反XSRF防御阻止跨域请求访问敏感数据。访问JSON对象的请求中应包含一个无法预测的参数，并且在返回数据前应对其进行确认。
(2)当应用程序从它自己的域中获取JSON对象时，并不仅限于使用<script>标签包含这个对象。因为请求在站内执行，客户端代码可以使用XMLHttpRequest自由访问响应数据，并可在将其作为JavaScript解释前对它进行其他处理。这意味着，为防止JOSN劫持，应用程序可以在响应的开始部分插入无效或有问题的JavaScript，客户应用程序在处理脚本前将会删除这些内容。
(3)由于应用程序可以使用XMLHttpRequest获取JSON数据，因此它也可以使用POST请求完成这项任务。如果应用程序仅接受使用POST访问JSON对象的请求，它就能够阻止第三方站点将这些请求包含在<script>标签内。
4 下载数据库并获取管理员信息,上传木马程序。。。
|
能力值：
( LV9，RANK：270 )
|
-
-
12 楼
题目1. 在通过提交专门设计的输入探查一个应用程序中是否存在常见的漏洞时，应用程序频繁返回包含调试信息的详细错误消息。有时，这些消息与其他用户造成的错误有关。这种情况发生一次后，就无法令其再次发生。这表示应用程序存在什么逻辑缺陷？接下来你该如何处理？
一、缓冲区溢出
二、程序二进制文件被修改（可能由于逻辑错误，造成的自修改）
三、程序辅助文件被修改（配置文件、注册文件、注册表项等）
反汇编调试一下
核对程序是否被修改，反汇编查看修改原因
查看程序辅助文件是否被修改
题目2. 要针对应用程序的一项敏感功能实施 XSRF 攻击，必须满足什么前提条件？
一、XSRF是基于浏览器的攻击，我觉得首先是浏览器必须支持请求的处理。（当然绝大多数浏览器都支持，不排除某些安全等级较高的机构使用特殊开发的专用浏览器）
二、用户标识。利用网站对用户标识的信任（cookie，session 和特殊应用标识）及信任时间窗机制。如果用户的每一次请求的提交都要进行严密的验证（用户名、密码、验证码等），我相信会给XSRF攻击带来一定的困难。
三、XSRF请求的构造，构造结构是多样的，图片tag、JavaScript等等。因此需要web程序本身支持一定的脚本（大多数都支持，比如论坛、blog等），并未对用户输入进行严格过滤，输出未严格转译。如对脚本字符进行严格过滤或转译，做好任何一点都可以减少XSRF攻击的发生。
题目3. 哪三种防御措施可用于防止 JSON 劫持攻击？
呵呵这个问题上面没说全面哈（主要是中午下班，着急吃饭去了。我们食堂要走好远的…………）
个人认为
一、应用层面对提交过来的请求进行过滤。如屏蔽对JSON对象的GET方法，因为 <script src=""> 来装在脚本文件使用的是GET方法。
二、使请求中的参数不可预测。
三、使JSON文件无法直接被外部访问，仅本地程序可以访问到。
四、在响应的开始部分插入无效或有问题的JavaScript，这个感觉不是很好。但是确实可以起到一定作用。如插入while(1);， 使JavaScript一直循环。但是这样毕竟破坏了json的格式，取巧的方法但不是很完美的方法。
|
能力值：
( LV3，RANK：20 )
|
-
-
13 楼
题目1. 在通过提交专门设计的输入探查一个应用程序中是否存在常见的漏洞时，应用程序频繁返回包含调试信息的详细错误消息。有时，这些消息与其他用户造成的错误有关。这种情况发生一次后，就无法令其再次发生。这表示应用程序存在什么逻辑缺陷？接下来你该如何处理？
答：根据题意该程序应该是多用户程序，调试信息中的错误与其他用户造成的错误有关，说明程序进程在处理多用户输入请求时，各个用户进程（或线程）是并发的，而程序进程在处理多用户请求时发生混乱，返回错误信息未发送到各个相应用户进程（或线程），导致出现与其他用户错误有关的调试信息。情况发生一次就不会再次发生，说明应用程序的处理流程发生了改变，如楼上所说可能是由于缓冲区溢出导致，或程序二进制文件改变等原因。总的来说存在的逻辑缺陷有可能是由于多用户并发请求，导致程序处理流程改变。处理办法应该先通过调试手段弄清程序处理用户输入的流程，找到导致流程改变的函数或指令，然后做相应的修改。
|
能力值：
( LV3，RANK：20 )
|
-
-
14 楼
题目2. 要针对应用程序的一项敏感功能实施 XSRF 攻击，必须满足什么前提条件？
答：1、跨站请求伪造一般会与跨站脚本攻击联合使用，这就先不要浏览器的支持脚本解析，才能实现跨站请求的顺利提交。
2、在跨站请求提交时，接受请求方应用程序未对请求发起者进行严格的身份验证。主要原因可能是存在用户身份令牌机制，在令牌失效前提交的请求是不需要再次验证的。
3、接受请求方应用程序对请求提交者提交请求时的身份验证不够严密，对影响重大的请求，应该采取多次验证机制，比如再次输入用户名、密码，或随机验证码、验证问题等。
4、用户对来历不明信息的信任。安全意识有待提高，呵呵。
|
能力值：
( LV12，RANK：200 )
|
-
-
15 楼
学习学习！！！！！！
|
能力值：
( LV2，RANK：10 )
|
-
-
16 楼
在书店看了一下这几本书，很一般。。
没看到英文版的不知是否翻译的问题。。
|
能力值：
( LV2，RANK：10 )
|
-
-
17 楼
我答不出，如果能答出来，这书也相当于看了一半了....不过还是顶下。。好想能读到
|
能力值：
( LV13，RANK：270 )
|
-
-
18 楼
题目1. 在通过提交专门设计的输入探查一个应用程序中是否存在常见的漏洞时，应用程序频繁返回包含调试信息的详细错误消息。有时，这些消息与其他用户造成的错误有关。这种情况发生一次后，就无法令其再次发生。这表示应用程序存在什么逻辑缺陷？接下来你该如何处理？
这种问题产生的可能，
如果关掉程序重新开，问题依然存在的话，
那肯定是二进制文件被破坏了，然后导致了程序的逻辑结构发生了变化。
接下来拿ida调试，或者用一个之前正确的版本，拿工具去对比下，看哪些地方破坏了。
如果重新打开程序，问题不存在了，那应该是用户的输入导致堆栈被破坏了，
拿od一步一步跟呗。。。
题目2. 要针对应用程序的一项敏感功能实施 XSRF 攻击，必须满足什么前提条件？
XSRF攻击这里就不详细说明了，
首先，其提交的参数是否会造成xss漏洞，如果没有xss，那也没法玩了。呵呵
再者，看表单是否还有time token的东西，如果有，也没办法利用了。
另外，好多程序加了关于refer的判断，来防止站外提交，但其实这种方法并不是最有效的，因为refer的值可以伪造。(谢谢楼下的)
题目3. 哪三种防御措施可用于防止 JSON 劫持攻击？
JSON劫持，新概念啊，感觉就是把javascript的函数给劫持了，然后改变其数据流，达到攻击的目的。如下方法：
应用程序应使用标准的反XSRF防御阻止跨域请求访问敏感数据。访问JSON对象的请求中应包含一个无法预测的参数，并且在返回数据前应对其进行确认。
当应用程序从它自己的域中获取JSON对象时，并不仅限于使用<script>标签包含这个对象。因为请求在站内执行，客户端代码可以使用XMLHttpRequest自由访问响应数据，并可在将其作为JavaScript解释前对它进行其他处理。这意味着，为防止JOSN劫持，应用程序可以在响应的开始部分插入无效或有问题的JavaScript，客户应用程序在处理脚本前将会删除这些内容。Google 在防止前述针对 GMail 的攻击时即采用了这种方法，在返回的脚本开始部分插入以下代码：
while(1);
由于应用程序可以使用XMLHttpRequest获取JSON数据，因此它也可以使用POST请求完成这项任务。如果应用程序仅接受使用POST访问JSON对象的请求，它就能够阻止第三方站点将这些请求包含在<script>标签内。
题目4. 假设受攻击的应用程序使用两台不同的服务器：一台应用程序服务器和一台数据库服务器。已经发现一个漏洞，可以在应用程序服务器上执行任意操作系统命令。那么如何利用这个漏洞获取保存在数据库中的敏感应用程序数据？
都可以执行任意操作系统命令了，这个应该很好办了吧。
拿脚本写个读数据库数据的程序，把读出来的东西保存到应用程序服务器上，不就可以了么。。
还有其它办法哈哈，就不细说了
(楼下的说没有写权限咋办，可是上面的前提是“任意操作系统命令”了，加个写权限不难吧，额。)
题目5. Linux、Apache、MySQL 与 PHP 等体系架构组件常被发现安装在同一台物理服务器上。为何这样做会削弱应用程序体系架构的安全状况？
LAMP结构，这题目，Linux是一个平台，Apache是服务器，PHP是语言。
想问下出题目的人，如果这三个不装在同一台物理服务器上，那应该怎么装？
对于MySQL,应该装到另外一台服务器上，这样做，虽然会出现第四题中的漏洞，但至少比装在同一台服务器上要安全。
题目6. 如果一个 Web 服务器允许通过 HTTP 与 HTTPS 访问它的功能，在查询漏洞时，使用这两个协议有何差别？
一个是未加密，一个是加密的，“在查询漏洞时”，是说在发现漏洞的过程中么？
利用https访问时，返回的数据包是加密的，并不是明文，但我们依然能通过浏览器看到它返回的内容。或者用firefox的firebug插件。默认的端口也不一样，所以没啥差别。他们的区别在于认证和传输的内容
|
能力值：
( LV3，RANK：20 )
|
-
-
19 楼
楼上说的防范XSRF 攻击用“refer的参数进行检查”的方法，我觉得有些不妥，首先refer的参数是可以伪造的。再次即使是来自本站的提交也不一定就是安全的啊。
对于题目4的看法，貌似不像楼上说的那么简单吧。
首先执行系统命令不一定有可写权限。
再者写脚本读数据库也要能得到连接账户和密码啊。
第三，应用服务器上如果对目录进行权限策略，想要将数据写到指定目录怕是没有那么简单吧。
其实这种情况下如果应用服务器部署严格，即使应用程序出了漏洞，想拿到数据库的敏感数据还是有一定难度的，曾经遇到过类似情况：web应用服务器+mssql数据库服务器，数据库服务器在外网无法访问，web服务器上装有网页防篡改系统，web程序可以sql注入，这样的部署使得web服务器根本无法写入脚本，只能通过sql注入查询数据库中指定的一点数据，查到的web管理员账户和密码还是加密过的，就算不加密也没啥用，因为根本找不到web程序管理的后台。一般遇到这样的情况多半会剑走边锋，看看管理员邮箱啊，QQ啊，密码也许和web后台的一样哈，然后解开了密码挨个试试。嘿嘿，有点邪恶哈。
|
能力值：
( LV3，RANK：20 )
|
-
-
20 楼
对于题目5
Linux属于操作系统层
Apache属于平台容器
MySQL数据库应用
PHP则是脚本支持
部署在不同机器上奇怪么？
Apache+PHP构成web程序发布的容器基础，可以部署在windows操作系统上，也可以部署在linux上。
MySQL自然也有windows版本和linux版本啊。
因此可将上述组件看做两部分：应用容器和数据库
部署方式：根据风险分散的原则，应该将两部分部署在不同主机的不同操作系统平台上，这样可以降低风险。嘻嘻，毕竟要精通windows系统和linux系统的专业黑客才能完全拿下这个系统，可以抵挡得住像偶一样的菜鸟哈。
|
能力值：
( LV2，RANK：10 )
|
-
-
21 楼
几天没来，又出新书了，学习！学习！
|
能力值：
( LV2，RANK：10 )
|
-
-
22 楼
不知道
不是很明白这种东西
|
能力值：
( LV2，RANK：10 )
|
-
-
23 楼
太高深了，学习学习！！
|
能力值：
( LV2，RANK：10 )
|
-
-
24 楼
答不出来，进来学习了
|
能力值：
( LV2，RANK：10 )
|
-
-
25 楼
有机会买一本学习学习。
|
|
|
|
