Layered Architecture web container configuration Security

Source: Internet
Author: User

// Ps: I thought this was a problem caused by accidental configuration errors. However, when I was bored in recent days, I found that there were hundreds of sites with similar problems, so here is a rough summary!

 

 

We usually encounter this problem. Direct access to sensitive information of applications deployed in a web container is forbidden. However, when two web containers are used together, due to security negligence, as a result, the private information of the former can be accessed over http, which is a very simple problem (which may be frequently encountered), but is often overlooked by deployment personnel, some tests have found that there are still many sites with such problems, including some large sites.

 

First look at this figure:

 

 

Found that the Tomcat container application under the WEB-INF folder can be accessed?

 

The above uses Nginx + Tomcat container layering and reverse proxy.

 

(

 

Nginx has good performance, simple configuration, and basically does not require software costs;

 

Tomcat is basically the same as Tomcat, but Tomcat has a disadvantage, resulting in low performance in processing static files.

 

Based on a series of reasons, some entrepreneurial or cost-effective Internet companies will choose j2ee and the two as the first choice for the website web Container layer architecture (there are many advantages, so we will not discuss them here ).

 

)

 

 

First, let's look:

 


 

The above only causes this problem. Two Typical Nginx configuration cases (many other scenarios ).

 

Cause: the root (access container) is configured in Nginx access transfer, which is usually the root path of the entire application, because it is easy to hand over static files to Nginx for processing.

 

First look at the application files in the WEB-INF Folder Security Description: http://baike.baidu.com/view/1745468.htm (familiar with j2ee is not much said !)

 

In the Tomcat container, the WEB-INF folders for all applications cannot be accessed directly through pages. Because the information in this folder is important, take a look at the following case: www.2cto.com/Article/201207/138673.html

Other site applications with the same problem (other sites with this problem will not be introduced here !) :

Due to the characteristics of the j2ee architecture, the entire application layer is exposed!

 

Of course, we will solve this problem through simple Nginx Configuration:

 

 

However, this configuration of Nginx is definitely not a Security Specification designed for j2ee security issues.

 

The same problem also occurs in the layered structure of Apache + Tomcat.

 

 

I would like to say that this problem is only manifested in the combination of web containers and the obvious security problems in the j2ee features. What about other languages or containers? In addition, do we need to pay more attention to the protection of sensitive information in two or more other specifications?

 

Simply put, how can one normative privacy problem be effectively protected in another?

 

Who should be responsible for this problem?

 

It is hard to say that the word "loose coupling" in the design standards is very useful. who is willing to take more responsibilities?

 

However, in Nginx + Tomcat, I personally think it is Nginx, because Tomcat has a low privilege in the layered architecture of the entire web Container!

 

To be more advanced products must be compatible (make this problem Nginx default security configuration, after all, WEB-INF folder is too important for j2ee !) Underlying products (of course, it depends on how this high-level product describes itself )!

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.