㈠ Tomcat下的J2EE WEB.XML配置文件信息泄露
web.xml
是在
WEB-INF目录下的，根据规范，WEB-INF目录
是禁止访问的，只能本地通过文件系统访问，你可以在文件系统中进行权限控制。
㈡ Tomcat下的J2EE WEB.XML配置文件信息泄露
web.xml 是在 WEB-INF目录下的，根据规范，WEB-INF目录 是禁止访问的，只能本地通过文件系统访问，你可以在文件系统中进行权限控制。
㈢ tomcat 怎样截止直接访问web.xml文件
项目中web.xml实在WEB-INF文件夹下的，tomcat有安全机制禁止浏览器直接访问WEB-INF文件夹下的任何文件
㈣ web漏洞攻击有哪些
一、SQL注入漏洞
SQL注入攻击（SQL Injection），简称注入攻击、SQL注入，被广泛用于非法获取网站控制权，是发生在应用程序的数据库层上的安全漏洞。在设计程序，忽略了对输入字符串中夹带的SQL指令的检查，被数据库误认为是正常的SQL指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。
通常情况下，SQL注入的位置包括：
（1）表单提交，主要是POST请求，也包括GET请求；
（2）URL参数提交，主要为GET请求参数；
（3）Cookie参数提交；
（4）HTTP请求头部的一些可修改的值，比如Referer、User_Agent等；
（5）一些边缘的输入点，比如.mp3文件的一些文件信息等。
常见的防范方法
（1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
（2）对进入数据库的特殊字符（’”<>&*;等）进行转义处理，或编码转换。
（3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
（5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
（7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
（8）在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。
二、跨站脚本漏洞
跨站脚本攻击（Cross-site scripting，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。
XSS攻击使用到的技术主要为HTML和Javascript，也包括VBScript和ActionScript等。XSS攻击对WEB服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。
XSS类型包括：
（1）非持久型跨站：即反射型跨站脚本漏洞，是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。
（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。
（3）DOM跨站（DOM XSS）：是一种发生在客户端DOM（Document Object Model文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。
常用的防止XSS技术包括：
（1）与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
（2）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
（4）对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
（5）在发布应用程序之前测试所有已知的威胁。
三、弱口令漏洞
弱口令(weak password) 没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则：
（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
（2）口令长度不小于8个字符。
（3）口令不应该为连续的某个字符（例如：AAAAAAAA）或重复某些字符的组合（例如：tzf.tzf.）。
（4）口令应该为以下四类字符的组合，大写字母(A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail地址等等与本人有关的信息，以及字典中的单词。
（6）口令不应该为用数字或符号代替某些字母的单词。
（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。
（8）至少90天内更换一次口令，防止未被发现的入侵者继续使用该口令。
四、HTTP报头追踪漏洞
HTTP/1.1（RFC2616）规范定义了HTTP TRACE方法，主要是用于客户端通过向Web服务器提交TRACE请求来进行测试或获得诊断信息。当Web服务器启用TRACE时，提交的请求头会在服务器响应的内容（Body）中完整的返回，其中HTTP头很可能包括Session Token、Cookies或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击，由于HTTP TRACE请求可以通过客户浏览器脚本发起（如XMLHttpRequest），并可以通过DOM接口来访问，因此很容易被攻击者利用。
防御HTTP报头追踪漏洞的方法通常禁用HTTP TRACE方法。
五、Struts2远程命令执行漏洞
ApacheStruts是一款建立Java web应用程序的开放源代码架构。Apache Struts存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java代码。
网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。CNVD处置过诸多此类漏洞，例如：“GPS车载卫星定位系统”网站存在远程命令执行漏洞(CNVD-2012-13934)；Aspcms留言本远程代码执行漏洞（CNVD-2012-11590）等。
修复此类漏洞，只需到Apache官网升级Apache Struts到最新版本：http://struts.apache.org
六、文件上传漏洞
文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网站服务器。
因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。
七、私有IP地址泄露漏洞
IP地址是网络用户的重要标示，是攻击者进行攻击前需要了解的。获取的方法较多，攻击者也会因不同的网络情况采取不同的方法，如：在局域网内使用Ping指令，Ping对方在网络中的名称而获得IP；在Internet上使用IP版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP包头信息，再根据这些信息了解具体的IP。
针对最有效的“数据包分析方法”而言，就可以安装能够自动去掉发送数据包包头IP信息的一些软件。不过使用这些软件有些缺点，譬如：耗费资源严重，降低计算机性能；访问一些论坛或者网站时会受影响；不适合网吧用户使用等等。现在的个人用户采用最普及隐藏IP的方法应该是使用代理，由于使用代理服务器后，“转址服务”会对发送出去的数据包有所修改，致使“数据包分析”的方法失效。一些容易泄漏用户IP的网络软件(QQ、MSN、IE等)都支持使用代理方式连接Internet，特别是QQ使用“ezProxy”等代理软件连接后，IP版的QQ都无法显示该IP地址。虽然代理可以有效地隐藏用户IP，但攻击者亦可以绕过代理，查找到对方的真实IP地址，用户在何种情况下使用何种方法隐藏IP，也要因情况而论。
八、未加密登录请求
由于Web配置不安全，登陆请求把诸如用户名和密码等敏感字段未加密进行传输，攻击者可以窃听网络以劫获这些敏感信息。建议进行例如SSH等的加密后再传输。
九、敏感信息泄露漏洞
SQL注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。针对不同成因，防御方式不同
十、CSRF
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的广泛使用，Web应用已经融入到日常生活中的各个方面：网上购物、网络银行应用、证券股票交易、政府行政审批等等。在这些Web访问中，大多数应用不是静态的网页浏览，而是涉及到服务器侧的动态处理。此时，如果Java、PHP、ASP等程序语言的编程人员的安全意识不足，对程序参数输入等检查不严格等，会导致Web应用安全问题层出不穷。
本文根据当前Web应用的安全情况，列举了Web应用程序常见的攻击原理及危害，并给出如何避免遭受Web攻击的建议。
Web应用漏洞原理
Web应用攻击是攻击者通过浏览器或攻击工具，在URL或者其它输入区域（如表单等），向Web服务器发送特殊请求，从中发现Web应用程序存在的漏洞，从而进一步操纵和控制网站，查看、修改未授权的信息。
1.1 Web应用的漏洞分类
1、信息泄露漏洞
信息泄露漏洞是由于Web服务器或应用程序没有正确处理一些特殊请求，泄露Web服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。
造成信息泄露主要有以下三种原因：
–Web服务器配置存在问题，导致一些系统文件或者配置文件暴露在互联网中；
–Web服务器本身存在漏洞，在浏览器中输入一些特殊的字符，可以访问未授权的文件或者动态脚本文件源码；
–Web网站的程序编写存在问题，对用户提交请求没有进行适当的过滤，直接使用用户提交上来的数据。
2、目录遍历漏洞
目录遍历漏洞是攻击者向Web服务器发送请求，通过在URL中或在有特殊意义的目录中附加“../”、或者附加“../”的一些变形（如“..\”或“..//”甚至其编码），导致攻击者能够访问未授权的目录，以及在Web服务器的根目录以外执行命令。
3、命令执行漏洞
命令执行漏洞是通过URL发起请求，在Web服务器端执行未授权的命令，获取系统信息，篡改系统配置，控制整个系统，使系统瘫痪等。
命令执行漏洞主要有两种情况：
–通过目录遍历漏洞，访问系统文件夹，执行指定的系统命令；
–攻击者提交特殊的字符或者命令，Web程序没有进行检测或者绕过Web应用程序过滤，把用户提交的请求作为指令进行解析，导致执行任意命令。
4、文件包含漏洞
文件包含漏洞是由攻击者向Web服务器发送请求时，在URL添加非法参数，Web服务器端程序变量过滤不严，把非法的文件名作为参数处理。这些非法的文件名可以是服务器本地的某个文件，也可以是远端的某个恶意文件。由于这种漏洞是由PHP变量过滤不严导致的，所以只有基于PHP开发的Web应用程序才有可能存在文件包含漏洞。
5、SQL注入漏洞
SQL注入漏洞是由于Web应用程序没有对用户输入数据的合法性进行判断，攻击者通过Web页面的输入区域(如URL、表单等) ，用精心构造的SQL语句插入特殊字符和指令，通过和数据库交互获得私密信息或者篡改数据库信息。SQL注入攻击在Web攻击中非常流行，攻击者可以利用SQL注入漏洞获得管理员权限，在网页上加挂木马和各种恶意程序，盗取企业和用户敏感信息。
6、跨站脚本漏洞
跨站脚本漏洞是因为Web应用程序时没有对用户提交的语句和变量进行过滤或限制，攻击者通过Web页面的输入区域向数据库或HTML页面中提交恶意代码，当用户打开有恶意代码的链接或页面时，恶意代码通过浏览器自动执行，从而达到攻击的目的。跨站脚本漏洞危害很大，尤其是目前被广泛使用的网络银行，通过跨站脚本漏洞攻击者可以冒充受害者访问用户重要账户，盗窃企业重要信息。
根据前期各个漏洞研究机构的调查显示，SQL注入漏洞和跨站脚本漏洞的普遍程度排名前两位，造成的危害也更加巨大。
1.2 SQL注入攻击原理
SQL注入攻击是通过构造巧妙的SQL语句，同网页提交的内容结合起来进行注入攻击。比较常用的手段有使用注释符号、恒等式（如1＝1）、使用union语句进行联合查询、使用insert或update语句插入或修改数据等，此外还可以利用一些内置函数辅助攻击。
通过SQL注入漏洞攻击网站的步骤一般如下：
第一步：探测网站是否存在SQL注入漏洞。
第二步：探测后台数据库的类型。
第三步：根据后台数据库的类型，探测系统表的信息。
第四步：探测存在的表信息。
第五步：探测表中存在的列信息。
第六步：探测表中的数据信息。
1.3 跨站脚本攻击原理
跨站脚本攻击的目的是盗走客户端敏感信息,冒充受害者访问用户的重要账户。跨站脚本攻击主要有以下三种形式：
1、本地跨站脚本攻击
B给A发送一个恶意构造的Web URL，A点击查看了这个URL，并将该页面保存到本地硬盘（或B构造的网页中存在这样的功能）。A在本地运行该网页，网页中嵌入的恶意脚本可以A电脑上执行A持有的权限下的所有命令。
2、反射跨站脚本攻击
A经常浏览某个网站，此网站为B所拥有。A使用用户名/密码登录B网站，B网站存储下A的敏感信息（如银行帐户信息等）。C发现B的站点包含反射跨站脚本漏洞，编写一个利用漏洞的URL，域名为B网站，在URL后面嵌入了恶意脚本（如获取A的cookie文件），并通过邮件或社会工程学等方式欺骗A访问存在恶意的URL。当A使用C提供的URL访问B网站时，由于B网站存在反射跨站脚本漏洞，嵌入到URL中的恶意脚本通过Web服务器返回给A，并在A浏览器中执行，A的敏感信息在完全不知情的情况下将发送给了C。
3、持久跨站脚本攻击
B拥有一个Web站点，该站点允许用户发布和浏览已发布的信息。C注意到B的站点具有持久跨站脚本漏洞，C发布一个热点信息，吸引用户阅读。A一旦浏览该信息，其会话cookies或者其它信息将被C盗走。持久性跨站脚本攻击一般出现在论坛、留言簿等网页，攻击者通过留言，将攻击数据写入服务器数据库中，浏览该留言的用户的信息都会被泄漏。
Web应用漏洞的防御实现
对于以上常见的Web应用漏洞漏洞，可以从如下几个方面入手进行防御：
1)对 Web应用开发者而言
大部分Web应用常见漏洞，都是在Web应用开发中，开发者没有对用户输入的参数进行检测或者检测不严格造成的。所以，Web应用开发者应该树立很强的安全意识，开发中编写安全代码；对用户提交的URL、查询关键字、HTTP头、POST数据等进行严格的检测和限制，只接受一定长度范围内、采用适当格式及编码的字符，阻塞、过滤或者忽略其它的任何字符。通过编写安全的Web应用代码，可以消除绝大部分的Web应用安全问题。
2) 对Web网站管理员而言
作为负责网站日常维护管理工作Web管理员，应该及时跟踪并安装最新的、支撑Web网站运行的各种软件的安全补丁，确保攻击者无法通过软件漏洞对网站进行攻击。
除了软件本身的漏洞外，Web服务器、数据库等不正确的配置也可能导致Web应用安全问题。Web网站管理员应该对网站各种软件配置进行仔细检测，降低安全问题的出现可能。
此外，Web管理员还应该定期审计Web服务器日志，检测是否存在异常访问，及早发现潜在的安全问题。
3）使用网络防攻击设备
前两种为事前预防方式，是比较理想化的情况。然而在现实中，Web应用系统的漏洞还是不可避免的存在：部分Web网站已经存在大量的安全漏洞，而Web开发者和网站管理员并没有意识到或发现这些安全漏洞。由于Web应用是采用HTTP协议，普通的防火墙设备无法对Web类攻击进行防御，因此可以使用IPS入侵防御设备来实现安全防护。
H3C IPS Web攻击防御
H3C IPS入侵防御设备有一套完整的Web攻击防御框架，能够及时发现各种已经暴露的和潜在的Web攻击。下图为对于Web攻击的总体防御框架。
图1：Web攻击防御框架，参见：http://blog.csdn.net/moshenglv/article/details/53439579
H3C IPS采用基于特征识别的方式识别并阻断各种攻击。IPS设备有一个完整的特征库，并可定期以手工与自动的方式对特征库进行升级。当网络流量进入IPS后，IPS首先对报文进行预处理，检测报文是否正确，即满足协议定义要求，没有错误字段；如果报文正确，则进入深度检测引擎。该引擎是IPS检测的核心模块，对通过IPS设备的Web流量进行深层次的分析，并与IPS攻击库中的特征进行匹配，检测Web流量是否存在异常；如果发现流量匹配了攻击特征，IPS则阻断网络流量并上报日志；否则，网络流量顺利通过。
此Web攻击防御框架有如下几个特点：
1) 构造完整的Web攻击检测模型，准确识别各种Web攻击
针对Web攻击的特点，考虑到各种Web攻击的原理和形态，在不同漏洞模型之上开发出通用的、层次化的Web攻击检测模型，并融合到特征库中。这些模型抽象出Web攻击的一般形态，对主流的攻击能够准确识别，使得模型通用化。
2) 检测方式灵活，可以准确识别变形的Web攻击
在实际攻击中，攻击者为了逃避防攻击设备的检测，经常对Web攻击进行变形，如采用URL编码技术、修改参数等。H3C根据Web应用漏洞发生的原理、攻击方式和攻击目标，对攻击特征进行了扩展。即使攻击者修改攻击参数、格式、语句等内容，相同漏洞原理下各种变形的攻击同样能够被有效阻断。这使得IPS的防御范围扩大，防御的灵活性也显着增强，极大的减少了漏报情况的出现。
3) 确保对最新漏洞及技术的跟踪，有效阻止最新的攻击
随着Web攻击出现的频率日益增高，其危害有逐步扩展的趋势。这对IPS设备在防御的深度和广度上提出了更高的要求，不仅要能够防御已有的Web攻击，更要有效的阻止最新出现的、未公布的攻击。目前，H3C已经建立起一套完整的攻防试验环境，可以及时发现潜在Web安全漏洞。同时还在继续跟踪最新的Web攻击技术和工具，及时更新Web攻击的特征库，第一时间发布最新的Web漏洞应对措施，确保用户的网络不受到攻击。
4) 保证正常业务的高效运行
检测引擎是IPS整个设备运行的关键，该引擎使用了高效、准确的检测算法，对通过设备的流量进行深层次的分析，并通过和攻击特征进行匹配，检测流量是否存在异常。如果流量没有匹配到攻击特征，则允许流量通过，不会妨碍正常的网络业务，在准确防御的同时保证了正常业务的高效运行。
结束语
互联网和Web技术广泛使用，使Web应用安全所面临的挑战日益严峻，Web系统时时刻刻都在遭受各种攻击的威胁，在这种情况下，需要制定一个完整的Web攻击防御解决方案，通过安全的Web应用程序、Web服务器软件、Web防攻击设备共同配合，确保整个网站的安全。任何一个简单的漏洞、疏忽都会造成整个网站受到攻击，造成巨大损失。此外 ，Web攻击防御是一个长期持续的工作，随着Web技术的发展和更新，Web攻击手段也不断发展，针对这些最新的安全威胁，需要及时调整Web安全防护策略，确保Web攻击防御的主动性，使Web网站在一个安全的环境中为企业和客户服务。
原文链接：
㈤ tomcat怎样禁止访问web.xml
第一步：修改应用程序的web.xml文件的协议
Xml代码
<?xmlversion="1.0"encoding="UTF-8"?>
<web-appxmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<?xmlversion="1.0"encoding="UTF-8"?>
第二步：在应用程序的web.xml中添加如下的代码即可
Xml代码
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
㈥ eclipse的web.xml文件出错
Tomcat配置问题，和你的jsp页面无关。如何配置Tomcat到eclipse：1. 首先本地要安装Tomcat；2. 选择Window-->preferences-->server-->runtime
㈦ web.xml的详细分析
1 定义头和根元素
部署描述符文件就像所有XML文件一样，必须以一个XML头开始。这个头声明可以使用的XML版本并给出文件的字符编码。
DOCTYPE声明必须立即出现在此头之后。这个声明告诉服务器适用的servlet规范的版本（如2.2或2.3）并指定管理此文件其余部分内容的语法的DTD(Document Type Definition，文档类型定义)。
所有部署描述符文件的顶层（根）元素为web-app。请注意，XML元素不像HTML，他们是大小写敏感的。因此，web-App和WEB-APP都是不合法的，web-app必须用小写。
2 部署描述符文件内的元素次序
XML 元素不仅是大小写敏感的，而且它们还对出现在其他元素中的次序敏感。例如，XML头必须是文件中的第一项，DOCTYPE声明必须是第二项，而web- app元素必须是第三项。在web-app元素内，元素的次序也很重要。服务器不一定强制要求这种次序，但它们允许（实际上有些服务器就是这样做的）完全拒绝执行含有次序不正确的元素的Web应用。这表示使用非标准元素次序的web.xml文件是不可移植的。
下面的列表给出了所有可直接出现在web-app元素内的合法元素所必需的次序。例如，此列表说明servlet元素必须出现在所有servlet-mapping元素之前。请注意，所有这些元素都是可选的。因此，可以省略掉某一元素，但不能把它放于不正确的位置。
l icon icon元素指出IDE和GUI工具用来表示Web应用的一个和两个图像文件的位置。
l display-name display-name元素提供GUI工具可能会用来标记这个特定的Web应用的一个名称。
l description description元素给出与此有关的说明性文本。
l context-param context-param元素声明应用范围内的初始化参数。
l filter 过滤器元素将一个名字与一个实现javax.servlet.Filter接口的类相关联。
l filter-mapping 一旦命名了一个过滤器，就要利用filter-mapping元素把它与一个或多个servlet或JSP页面相关联。
l listener servlet API的版本2.3增加了对事件监听程序的支持，事件监听程序在建立、修改和删除会话或servlet环境时得到通知。Listener元素指出事件监听程序类。
l servlet 在向servlet或JSP页面制定初始化参数或定制URL时，必须首先命名servlet或JSP页面。Servlet元素就是用来完成此项任务的。
l servlet-mapping 服务器一般为servlet提供一个缺省的URL：http://localhost/webAppPrefix/servlet/ServletName。但是，常常会更改这个URL，以便servlet可以访问初始化参数或更容易地处理相对URL。在更改缺省URL时，使用servlet-mapping元素。
l session-config 如果某个会话在一定时间内未被访问，服务器可以抛弃它以节省内存。可通过使用HttpSession的setMaxInactiveInterval方法明确设置单个会话对象的超时值，或者可利用session-config元素制定缺省超时值。
l mime-mapping 如果Web应用具有想到特殊的文件，希望能保证给他们分配特定的MIME类型，则mime-mapping元素提供这种保证。
l welcom-file-list welcome-file-list元素指示服务器在收到引用一个目录名而不是文件名的URL时，使用哪个文件。
l error-page error-page元素使得在返回特定HTTP状态代码时，或者特定类型的异常被抛出时，能够制定将要显示的页面。
l taglib taglib元素对标记库描述符文件（Tag Libraryu Descriptor file）指定别名。此功能使你能够更改TLD文件的位置，而不用编辑使用这些文件的JSP页面。
l resource-env-ref resource-env-ref元素声明与资源相关的一个管理对象。
l resource-ref resource-ref元素声明一个资源工厂使用的外部资源。
l security-constraint security-constraint元素制定应该保护的URL。它与login-config元素联合使用
l login-config 用login-config元素来指定服务器应该怎样给试图访问受保护页面的用户授权。它与sercurity-constraint元素联合使用。
l security-role security-role元素给出安全角色的一个列表，这些角色将出现在servlet元素内的security-role-ref元素的role-name子元素中。分别地声明角色可使高级IDE处理安全信息更为容易。
l env-entry env-entry元素声明Web应用的环境项。
l ejb-ref ejb-ref元素声明一个EJB的主目录的引用。
l ejb-local-ref ejb-local-ref元素声明一个EJB的本地主目录的应用。
3 分配名称和定制的UL
在web.xml中完成的一个最常见的任务是对servlet或JSP页面给出名称和定制的URL。用servlet元素分配名称，使用servlet-mapping元素将定制的URL与刚分配的名称相关联。
3.1 分配名称
为了提供初始化参数，对servlet或JSP页面定义一个定制URL或分配一个安全角色，必须首先给servlet或JSP页面一个名称。可通过 servlet元素分配一个名称。最常见的格式包括servlet-name和servlet-class子元素（在web-app元素内），如下所示：
Xml代码
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>
这表示位于WEB-INF/classes/moreservlets/TestServlet的servlet已经得到了注册名Test。给 servlet一个名称具有两个主要的含义。首先，初始化参数、定制的URL模式以及其他定制通过此注册名而不是类名引用此servlet。其次,可在 URL而不是类名中使用此名称。因此，利用刚才给出的定义，URL http://localhost/webAppPrefix/servlet/Test 可用于 http://localhost/webAppPrefix/servlet/moreservlets.TestServlet 的场所。
请记住：XML元素不仅是大小写敏感的，而且定义它们的次序也很重要。例如，web-app元素内所有servlet元素必须位于所有servlet- mapping元素（下一小节介绍）之前，而且还要位于5.6节和5.11节讨论的与过滤器或文档相关的元素（如果有的话）之前。类似地，servlet 的servlet-name子元素也必须出现在servlet-class之前。5.2节部署描述符文件内的元素次序将详细介绍这种必需的次序。
例如，程序清单5-1给出了一个名为TestServlet的简单servlet，它驻留在moreservlets程序包中。因为此servlet是扎根在一个名为deployDemo的目录中的Web应用的组成部分，所以TestServlet.class放在deployDemo/WEB- INF/classes/moreservlets中。程序清单5-2给出将放置在deployDemo/WEB-INF/内的web.xml文件的一部分。此web.xml文件使用servlet-name和servlet-class元素将名称Test与TestServlet.class相关联。图 5-1和图5-2分别显示利用缺省URL和注册名调用TestServlet时的结果。
㈧ parseerroratline1,column1
关于parseerroratline1,column1相关资料如下
这个问题，后来发现在编译后的target中对应的报错文件web.xml是空的。
而这个空文件web.xml在工程的的另一个子工程中的WEB-INF下。
把它删掉后，启动就不会报错了。但是启动成功后，浏览器又开始报404错误。
原来是，我的启动工程Artifacts定义的是longking这个包。而web.xml,需要的也是这工程里的。检查发现，这个工程下的target没有web.xml(原先的long-king中的web.xml被我删掉了，所以编译后，这里也没有)。于是把longking的wen.xml复制到target中即可。
㈨ Web应用和web.xml文件
手动建立一个Web应用，一般按照以下步骤执行：
通过上述5个步骤已经建立了一个空的Web应用，将该Web应用复制到Tomcat的webapps路径下，该Web应用就可以自动部署在Tomcat服务器中了。
通过手动建立一个Web应用可以发现Web应用的结构如下：
通常只需将JSP页面放在Web应用的根路径下（对于本例而言，就是放在webDemo目录下），然后就可以通过浏览器来访问页面了。下面编写一个index.jsp页面，然后将该页面放在webDemo路径下，通过浏览器访问该页面。
web.xml文件位于每个web应用的WEB-INF路径下，是Web应用的配置描述文件，主要用来配置管理Web应用的大部分组件，从Servlet3.0开始，也可以通过注解来配置管理Web组件。web.xml文件配置和管理的内容主要有以下：
关于web.xml文件的编写将在后续的学习中展开，这里只做简单的介绍。
㈩ tomcat 9 安全加固
Apache Tomcat 9 (9.0.53) - Security Considerations
在tomcat-users.xml中停用所有用户，默认就没开
推荐加固方式：
另一种方法：
还可以设置port属性为 -1 ，关闭 shutdown port
将host节点的autoDeploy属性设置为“false”
如果存在deployOnStartup属性，也将其更改为“false”
server.xml
默认就有如下配置，不用修改
server="" 也行
server.xml
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Error_Report_Valve
修改Error_Report_Valve属性为 false ，解决报错泄露
添加好host部分
web.xml
修改DefaultServlet 配置 showServerInfo 属性为 false
或者，创建文件 CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties ，内容为：
或者
进入 apache-tomcat-9.0.53/lib/ 目录，执行如下：
如上会从 catalina.jar 解压 org/apache/catalina/util/ServerInfo.properties 文件，文件内容如下：
修改 server.info 和 server.number
执行如下，将 org/apache/catalina/util/ServerInfo.properties 打包进 catalina.jar
编辑web.xml 文件中配置，将readonly 的param-value值设为false
org.apache.catalina.servlets.DefaultServlet的
conf/web.xml
将listings的值设置为false。
conf/web.xml
web-app添加子节点：
在webapps目录下创建 ROOT/404.html ，定义自定义错误信息。范例如下：
添加 64*64 的LOGO到 <Tomcat_Home>/webapps/ROOT/favicon.ico