Grizzly 项目是否处理缓冲区溢出或拒绝服务攻击?

发布于 2024-10-08 03:02:46 字数 991 浏览 0 评论 0原文

我已经搜索了很多,但仍然不明白使用 Grizzly 是否意味着我可以免受这些攻击,或者我应该付出更多努力?

目前,我在程序中做的唯一一件事就是通过以下代码将资源类(由 @Path 注释 - 我正在使用 Jersey)部署到 Grizzly:

final Map<String, String> initParams = new HashMap<String, String>();
initParams.put("com.sun.jersey.config.property.packages","MyServer.resources");
SelectorThread threadSelector;
try{
    threadSelector = GrizzlyWebContainerFactory.create(
 uri, initParams);
    System.out.println("Press enter to stop server...");
    System.in.read();
    threadSelector.stopEndpoint();
}catch(...){...}

在我的资源方法中,我可以访问 JAXB 列表我没有为其指定任何大小(我不知道此时是否可以检查大小以避免收到大的请求 - 如果可能的话,如果有人告诉我,这将是一个很大的帮助! ),所以,我担心攻击者可能会发送连续的大请求(我的正常请求大小应该小于 6 个 bean!)并导致拒绝服务 - 我刚刚开始学习安全风险并处理它们,我的第一次尝试!

我将检查请求处理程序方法主体中的大小,这是在服务器完全接收到请求之后。够了吗?

Grizzly 文档说它有良好的缓冲区管理(我可能将缓冲区溢出与拒绝服务混合在一起),但我不知道是否应该设置任何设置,还是默认保护?

编辑:

我已经收到了我的部分问题的良好答案,但是,我仍在寻找一些提示,特别是关于 Grizzly 或 Jersey 的提示,以及是否有一个单一的入口点,我可以在其中对所有传入请求进行一些检查?

谢谢!

I have searched a lot, but still don't understand whether using Grizzly means that I am protected against those attacks or that I should do some more effort?

Currently, the only thing I do in my program is that I deploy my resource classes (annotated by @Path - I'm using Jersey) to the Grizzly, by the following code:

final Map<String, String> initParams = new HashMap<String, String>();
initParams.put("com.sun.jersey.config.property.packages","MyServer.resources");
SelectorThread threadSelector;
try{
    threadSelector = GrizzlyWebContainerFactory.create(
 uri, initParams);
    System.out.println("Press enter to stop server...");
    System.in.read();
    threadSelector.stopEndpoint();
}catch(...){...}

In my resource methods, I may access a list of JAXB beans which I don't specify any size for it (I don't know if it is possible to check the size at this point to avoid getting large requests-if it is possible, it will be a great help if somebody tell me!), So, I'm afraid that an attacker may send consecutive and large requests (my normal request size should be less than 6 beans!) and result to denial of service - I am just starting to learn security risks and handling them, my first attempt!

I will check the size in the request handler method's body, which is after the request is completely received by the server. Is it enough?

The Grizzly documents say that it has a good buffer management (I may be mixing buffer overflow with denial of service), but I don't know whether I should set any settings or is it by default protecting?

EDIT:

I have received a good answer to part of my question, but, I'm still looking for some hints particularly about the Grizzly or Jersey and whether there is a single point of entry in which I can make some checks for all incoming requests?

Thanks!

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

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

发布评论

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

评论(1

清醇 2024-10-15 03:02:46

如果您使用 Java,那么您几乎不会受到经典缓冲区溢出攻击的影响,除非您使用本机代码库来处理从网络获取的内容。

另一方面,保护自己免受拒绝服务攻击往往需要采用整体系统方法。

编辑

通过“整个系统”方法,我的意思是一种考虑对网络带宽、基础设施和后端服务器以及 Web 服务器的影响的方法。例如,无论您如何实现网络服务器,针对您的网络带宽或 DNS 的攻击都可能导致您无法使用无线网络。在另一端,有人可以针对您的 Web 应用程序的各个方面;例如,知道特定查询非常昂贵......或者它泄漏资源并最终使您的应用程序崩溃。

(我不是这方面的专家。我只是想指出,如果您真的关心防御 DDoS,那么仅仅查看您的 Web 服务器平台是不够的。)

If you are using Java you are pretty much immune from classic buffer overrun attacks, unless you are using native code libraries to process stuff you get from the net.

On the other hand, protecting yourself from denial of service attacks tends to require a whole-of-system approach.

EDIT

By "whole of system" approach, I mean one that takes account of the impact on your network bandwidth, infrastructure and back-end servers as well as just your web server. For instance, an attack directed at your network bandwith or DNS can take you off the air irrespectively of how you implement your webserver. At the other end, someone could target aspects of your web application; e.g. knowledge that a particular query is very expensive ... or that it leaks resources and eventually crashes your application.

(I'm not an expert on this. I'm just trying to point out that just looking at your web server platform is not sufficient ... if you really care about defending against DDoS.)

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