一般如何发现客户端安全漏洞？
我的意思是在操作系统或其应用程序中。我能想到的唯一方法是检查二进制文件是否使用了 strcpy() 等危险函数，然后尝试利用这些函数。尽管随着编译器的改进（例如 Visual Studio 的 /GS 开关），这种可能性应该已经成为过去。还是我错了？
人们还使用哪些其他方法来查找漏洞？只需将目标加载到调试器中，然后发送意外的输入，看看会发生什么？这似乎是一个漫长而乏味的过程。
谁能推荐一些关于这个主题的好书或网站？
提前致谢。
I mean in operating systems or their applications. The only way I can think of is examine binaries for the use of dangerous functions like strcpy(), and then try to exploit those. Though with compiler improvements like Visual Studio's /GS switch this possibility should mostly be a thing of the past. Or am I mistaken?
What other ways do people use to find vulnerabilities? Just load your target in a debugger, then send unexpected input and see what happens? This seems like a long and tedious process.
Could anyone recommend some good books or websites on this subject?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“客户端安全”涉及两个主要问题。
目前最常见的客户端是“Drive By Downloads”形式的浏览器。最常见的原因是内存损坏漏洞。 ActiveX com 对象一直是 Windows 系统上的常见路径，AxMan 是一个很好的 ActiveX 模糊器。
就内存保护系统而言，/GS 是一个金丝雀，它并不是阻止缓冲区溢出的全部目的。它仅旨在保护试图覆盖返回地址并控制 EIP 的基于堆栈的溢出。 NX 区域和金丝雀是一件好事，但 ASLR 在阻止内存损坏漏洞方面可以做得更好，而且并非所有 ASLR 实现都同样安全。即使使用所有这三个系统，您仍然会受到黑客攻击。在 Windows 7 上运行的 IE 8 拥有这一切，它是 pwn2own 上最先被黑客攻击的浏览器之一，这里是 他们是如何做到的。它涉及将堆溢出和悬空指针漏洞链接在一起。
“客户端安全”的问题是CWE-602：服务器端强制执行-当服务器端信任客户端的秘密资源（如密码）或发送有关敏感信息的报告（例如玩家得分的最佳方法是什么。
查找客户端问题的最佳方法是查看流量。 WireShark 最适合非浏览器客户端/服务器协议。然而 TamperData 是迄今为止可以用于浏览器的最佳工具基于 Flash 和 JavaScript 等平台。每种情况都会有所不同，与缓冲区溢出不同，缓冲区溢出很容易看到进程崩溃，客户端信任问题都与上下文有关，需要熟练的人员查看网络流量才能找出问题。
有时，愚蠢的程序员会将密码硬编码到他们的应用程序中。反编译应用程序以获取数据很简单。 Flash 反编译非常干净，您甚至可以获得完整的变量名称和代码注释。另一种选择是使用 OllyDBG 之类的调试器来尝试查找内存中的数据。 IDA-Pro 是 C/C++ 应用程序的最佳反编译器。
There are two major issues involved with "Client Side Security".
The most common client exploited today is the browser in the form of "Drive By Downloads". Most often memory corruption vulnerabilities are to blame. ActiveX com objects have been a common path on windows systems and AxMan is a good ActiveX fuzzer.
In terms of memory protection systems the /GS is a canary and it isn't the be all end all for stopping buffer overflows. It only aims to protect stack based overflows that are attempting to overwrite the return address and control the EIP. NX Zones and canaries are a good things, but ASLR can be a whole lot better at stopping memory corruption exploits and not all ASLR implementations are made equally secure. Even with all three of these systems you're still going to get hacked. IE 8 Running on Windows 7 had all of this and it was one of the first to be hacked at the pwn2own and here is how they did it. It involved chaining together a Heap Overflow and a Dangling Pointer vulnerability.
The problem with "client side security" is CWE-602: Client-Side Enforcement of Server-Side Security are created when the server side is trusting the client with secret resources (like passwords) or to send report on sensitive information such as the Players Score in a flash game.
The best way to look for client side issues is by looking at the traffic. WireShark is the best for non-browser client/server protocols. However TamperData is by far the best tool you can use for browser based platforms such as Flash and JavaScript. Each case is going to be different, unlike buffer overflows where its easy to see the process crash, client side trust issues are all about context and it takes a skilled human to look at the network traffic to figure out the problem.
Sometimes foolish programmers will hardcode a password into their application. Its trivial to decompile the app to obtain the data. Flash decompiling is very clean, and you'll even get full variable names and code comments. Another option is using a debugger like OllyDBG to try and find the data in memory. IDA-Pro is the best decompiler for C/C++ applications.
编写安全代码，第二版，包括一些关于威胁建模和测试的内容，等等。
Writing Secure Code, 2nd edition, includes a bit about threat modeling and testing, and a lot more.