破解你自己的应用程序

发布于 2024-07-13 10:25:59 字数 187 浏览 12 评论 0原文

我是一名 Web 开发人员,非常注重安全性,并尝试使我的 Web 应用程序尽可能安全。

我是如何开始用 C# 编写自己的 Windows 应用程序的,当谈到测试我的 C# 应用程序的安全性时,我真的只是一个新手。

只是想知道是否有人有关于如何破解您自己的 Windows 应用程序和编写安全代码的任何好的教程/自述文件。

I am a web developer that is very conscious of security and try and make my web applications as secure as possible.

How ever I have started writing my own windows applications in C# and when it comes testing the security of my C# application, I am really only a novice.

Just wondering if anyone has any good tutorials/readme's on how to hack your own windows application and writing secure code.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

欢你一世 2024-07-20 10:25:59

迈克尔·霍华德的书是一个很好的起点;

Michael Howard 的博客中有大量链接和有趣的文章 此处

Microsoft 有一个有趣的 Powerpoint 演示,内容涉及威胁评估、风险和 ASP 此处

The books by Michael Howard are a good starting point;

There's loads of links and interesting articles from Michael Howard's blog here

There's an interesting powerpoint presentation from Microsoft about threat assessment, risks and ASP here.

白云不回头 2024-07-20 10:25:59

除了防止缓冲区溢出、代码注入、会话劫持等所有明显的答案之外。 等人。 您应该找其他人来检查您的代码/软件,因为您只能考虑如何破解您知道如何防止的软件。 仅仅因为您找不到破解自己软件的方法,并不意味着其他人也可以。

Apart from all the obvious answers to prevent buffer overflows, code injection, session highjacking et. al. you should find somebody else to check your code/software because you can only think about ways to hack your software that you know how to prevent. Only because you can’t find a way to hack your own software that doesn’t mean that nobody else can.

柏拉图鍀咏恒 2024-07-20 10:25:59

这对你来说是很难做到的事情,我认为你从错误的角度来处理这个问题。 如果您正在编写任何大小的应用程序,那么试图通过寻找破坏您自己的软件的特定方法来最终处理安全性几乎是不可能的。

这是出于多种原因。 您已经以某种方式考虑您的软件。 你会想到与之互动的具体方式,并且知道如何从中获得最好的效果。 您不会考虑如何利用它,而对于您非常熟悉的软件来说,这是一件很难做到的事情。

另一个问题是,此时的任务太大,难以处理。 您发现的任何问题都可能会引发许多其他问题。 系统范围的安全检查还不够细致。

您应该做的是在编写软件时考虑安全性。 了解最佳实践,并从安全角度考虑您编写的每个方法和类。 这与单元测试密切相关,尝试考虑哪些输入可能会使我的程序的这个特定部分中断。 然后在那个级别处理他们。

之后,我认为问题是快速响应您意识到的任何安全问题。

This is something that is very difficult for you to do, and I think that you are approaching the problem from the wrong angle. If you are writing an application of any size then attempting to deal with security at the end, by looking for specific ways of breaking your own software, is almost impossible.

This is for a number of reasons. You already think about your software in a certain way. You think of specific ways of interacting with it, and you know how to get the best from it. You don't think about it in terms of ways to exploit it, and this is a hard thing to do with software that you are intimately familiar with.

Another problem is that the task by this point is too big to deal with. Any problems that you do find may open up any number of other problems. A system wide security check is nowhere near granular enough.

What you should be doing is thinking about security while you write the software. Learn the best practices, and consider each method and class that you write from a security perspective. This goes hand in hand with unit testing, try to consider what inputs could make this specific part of my program break. and then deal with them at that level.

After that I think its a matter of responding quickly to any security concerns that you are made aware of.

谷夏 2024-07-20 10:25:59

我通过自己的经历遇到的一些小事情。

  • 不要使用动态 SQL,否则很容易受到 SQL 注入的攻击。 而是使用带参数的 SQL 查询。
  • 没有像 user_id = 1, 2, 3 等递增的 id,然后在 URL 中使用它,something.aspx?user_id=1,然后我可以猜测下一个 id 和会话希望。 帐户和其他敏感内容也是如此。
  • 提防 XSS(跨站脚本)。 如果您接受用户输入并直接存储它,请确保他们无法为其姓名或其他内容插入alert()。

这绝不是完整的列表。 只是我最近遇到的事情。

Small things that I have come across through my own experience.

  • Do not use dynamic SQL, you are then vulnerable to SQL injection. Rather use SQL queries with parameters.
  • Do not have incrementing ids like user_id = 1, 2, 3 etc etc and then use that in a URL, something.aspx?user_id=1, i can then guess the next id and session hope. Same for accounts and what ever else is sensitive.
  • Watch out for XSS, (cross site scripting). If you accept user input and store it directly, make sure that they can't go insert alert() for their name or something.

This is by no means a complete list. Just the stuff that I have run into recently.

戈亓 2024-07-20 10:25:59

您可能会比阅读 Ross Anderson 的安全工程书做得更糟糕。 第一版可以 PDF 格式下载,非常值得一读。 我还没有读过第二版,但我怀疑它更好并且有更多好东西。

请注意,这本书解释了如何从一开始就构建安全性,而不是如何破坏安全性,但对各种安全错误的阐述应该让您知道从哪里开始寻找。

You could do much worse than reading Ross Anderson's Security Engineering book. The first edition is downloadable as a PDF and is a good read. I haven't read the second edition, but I suspect it's better and has more goodies in it.

Do note it is a book that explains how to build security in from the start, not how to break security, but the exposition of assorted security faults should give you a good idea for where to start looking.

很酷不放纵 2024-07-20 10:25:59

为了保护您的 win 表单应用程序,请打开它并尝试执行 lambda 用户不应该执行的所有操作! 我将解释:

如果您“输入 yesno”,请尝试使用 AZ, 0-9,因为这就是某些用户尝试查找堆栈跟踪的方法可能很有趣。 所以到处都放验证器。

请注意与数据库的连接,但如果您来自网络开发人员,您应该比我更清楚:)。

最困难的部分是注意内存泄漏或类似的东西,但这是在大型应用程序或开发不完善的应用程序中。

To secure your win form application open it and try to do everything that lambda user shouldn't do! I'll explain:

If you "say enter yes or no", try with A-Z, 0-9 because that's what some users do to try to find some stack trace that could be interesting. So put validators everywhere.

Beware of connection to databases but if you come from web dev you should be more aware than me :).

The hardest part is to watch out about memory leaks or stuff like that, but that's in big big apps or in not well developed apps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文