Configuration security for Layered architecture web containers

Source: Internet
Author: User

Transferred from: Http://hi.baidu.com/shineo__o/item/7520d54c24d234c71081da82

/ps: I thought this is a accidental configuration error caused by the problem, but in recent days bored test found that there are similar problems of the site there are hundreds, so here rough summary!

Usually we encounter a problem where the sensitive information of the application deployed in a Web container is not directly accessible, but requires two web containers to be used together, and because of the negligence of security awareness, the former's private information can be accessed via HTTP, a very simple problem (which may be often encountered), But often easy to be ignored by the deployment, the previous period of time to test the site of such problems, there are many large sites.

Look at this picture first:

Found under the Web-inf folder under the Tomcat container can be accessed?

Above is the use of Nginx + Tomcat container layered, do a reverse proxy.

Nginx because of good performance, simple configuration, and basically do not need software costs;

Tomcat is the same as above, but Tomcat has a disadvantage in dealing with static files with poor performance.

A series of reasons, for some entrepreneurial or cost-cutting internet companies, will choose the Java EE and both as the Site Web container Layer architecture preferred (there are many advantages, not to discuss it here).

First, look at:



The above is only the case that led to this problem, two typical nginx configurations (other scenarios are also more).

Reason: The configuration of root (Access container) in Nginx access transfer is usually the root path of the entire application, as it is easy to give the static file to Nginx for processing.

First look at the Web-inf folder in the application file security instructions: http://baike.baidu.com/view/1745468.htm (familiar with the Java EE is not much to say!) )

In the Tomcat container, all apps ' Web-inf folders are not directly accessible through the page. Because the information in this folder is important, harm looks at one of the following cases:

http://www.wooyun.org/bugs/wooyun-2010-07329

Other site applications of the same problem (other sites with this problem are not introduced!) ):

http://www.wooyun.org/bugs/wooyun-2010-07760

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

Of course, we will solve this problem through Nginx's simple configuration:

But Nginx's configuration is definitely not a security specification for the security of the Java EE.

The same problem arises in the hierarchical structure of Apache + tomcat.

I would like to say that this problem is only in the Web container collocation, in the characteristics of the Java EE is manifested by the obvious security issues. That other language or other container? Or should we be more aware of the protection of sensitive information in two or more other specifications?

Simply put, how does one normative privacy issue be effectively protected in another specification?

So who's the security problem or who's responsible?

Not to say, design standards in the "loose coupling" The word is very good, who is willing to take the initiative to assume more responsibility?

However, from Nginx + tomcat, the personal view is Nginx, because Tomcat has a low weight in the entire Web container layering architecture!

To do higher-level products must be compatible (let this problem become nginx default security configuration items, after all, Web-inf folder for the Java EE is too important!) The bottom product (of course, depends on how this high-level product describes itself)!

Configuration security for Layered architecture web containers

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.