三、其他类别

　　这些类别的范围就有点大了，可以包括数据库如SQL Server、Oracle 、DB2等的漏洞，也可以包括操作系统如WindowsNT/2000、Linu等的漏洞。这些东西的漏洞可以说都是致命的，如利用Linux的某些漏洞可以轻易获得管理员权限来远程控制服务器，获得系统的完全控制权限，这样要获得jsp源代码或者摧毁服务器比踩死一只蚂蚁还要轻松的多。

　　四、全文总结

　　通过上面内容可以看出jsp同asp一样还是存在着很多安全上的问题的，客观的说，服务器软件的开发商在内部测试中不可能将系统中的所有bug 找出来，即使发布了软件后，被发现的漏洞也只会是其中的很小一部分，将来还会不断的有新的安全问题出现，所以我们必须时刻提高警惕，并注意自己网站的安全。

　　一个好的建议就是多看安全文章，这些安全文章一般都会有详细的信息如软件的版本号、漏洞原因等等，最重要的是还附带了解决办法或者是补丁的下载链接，推荐的安全站点是国内的安全站点www.cnns.net或者国外的http://www.securityfocus.com站点；另外一个好的建议就是多装补丁程序，访问自己所使用的软件公司主页，从那上面获得最新的补丁程序，做得比较好的就是微软的站点，安全公告和补丁都特别及时。

　　最后想用一句话作为全文的结尾：一个优秀的黑客不一定是个好的jsp 程序员，一个优秀的jsp程序员一定要是个好的准黑客。

　　哪些方式可实现Java Servlet及JavaScript/" target="_blank">JSP的应用安全？

　　一个web 应用程序可拥有多种资源，经常有许多敏感的信息在没有保护措施的情况下在开放性网络上传输。在这种环境下，实际上许多web 应用程序有一定程度的安全性要求。大多数的servlet 容器有明确的机制和结构来达到这种安全要求。虽然保证和执行的细节可能有些不同，但是，都具有下面的特点：

　　1．Authentication：通讯实体相互验证对方的行为是以一个明确的身份在进行的一种机制。
　　2．Access control for resources：对某组用户来说，对数据库的某些操作是受到限制的，或对有些程序强调可用性，完整性或保密性的一种机制。
　　3．Data Integrity：数据在传递过程中保证不被第三方修改的一种机制。
　　4．Confidentiality or Data Privacy：保证数据只被那些授权使用的用户使用，能被安全传递的一种机制。

　　Java Servlet，JavaScript/" target="_blank">JSP中安全性通过如下几种方式实现：

　　一、 Declarative Security

　　Declarative security指的是表达一个应用的安全结构，包括角色，存取控制，和在一个应用的外部表单所要求的验证。在web application中发布描述器是实施declarative security的一种主要的工具。

　　发布者把application所要求的逻辑完整性映射为在特定运行环境下的安全策略。在运行时，servlet container使用这些策略来强迫验证。

　　二 、Programmatic Security

　　当declarative security不能够完全表达一个application的安全模型时，就可以使用programmatic Security。Programmatic Security包括HttpServletRequest接口的下列方法：
　　getRemoteUser
　　isUserInRole
　　getUserPrincipal

　　getRemoteUser方法返回经过客户端验证的用户名。IsUserInRole向container的安全机制询问一个特定的用户是否在一个给定的安全角色中。GetUserPrinciple方法返回一个Java.security.Pricipal对象。这些APIs根据远程用户的逻辑角色让servlet去完成一些逻辑判断。它也可以让servlet去决定当前用户的主要名字。如果getRemoteUser返回null值（这意味着没有用户被验证），那么isUserInRole就总会返回false，getUserPrinciple总会返回null。

　　三 、Roles

　　一个Roles就是由Application Developer和Assembler所定义的一个抽象的逻辑用户组。当一个application被发布的时候，Deployer就把这些角色映射到在运行环境中的安全认证，例如组或规则。

　　一个servlet container能够为规则执行一些说明或编程安全，这些规则是与调用这些principal的安全属性所输入的要求相联系的。例如：

　　1．当deployer把一个安全角色映射为操作环境下的一个用户组，调用principle所属的用户组就从安全属性中获得。如果principle的用户组与在操作环境下的用户组相匹配，那么principle 就是一个安全角色。
　　2．当deployeer把一个安全角色映射为一个在安全方针域中的principle名时，调用principle的确principle名就被从安全属性中提取出来。如果两者相同的话，调用的principle就是安全的。

　　四、Authentication

　　一个web 客端能够使用下面的一种机制来对web 服务器验证一个用户。

　　HTTP Digest Authentication
　　HTTPS Client Authentication
　　HTTP Basic Authentication
　　HTTP Based Authentication

　　五、HTTP Basic Authentication

　　HTTP Basic Authentication是一个定义在HTTP/1.1规范中的验证机制。这种机制是以用户名和密码为基础的。一个web server要求一个web client去验证一个用户。作为request的一部分，web server 传递被称之为realm的字符串，用户就是在它里面被验证的。注意：Basic Authentication机制的realm字符串不一定反映任何一种安全方针域。Web client得到这些用户名和密码，然后把它传递给web server。Web server然后在一个特定的领域验证这些用户。

　　由于密码是使用一种64位的编码来传递，而且目的server没有验证，所以Basic Authentication不是一种安全的验证协议。然而一些附加的保护像使用一种安全传输机制（HTTPS）或在网络层使用安全措施能够解决一些问题。

　　六、HTTP Digest Authentication

　　与HTTP Digest Authentication一样，HTTP Digest Authentication根据用户名和密码验证一个用户。然而密码的传输是通过一种加密的形式进行的，这就比Basic Authentication所使用的64位编码形式传递要安全的多。这种方法没有像HTTPS Client Authentication的个人密钥方案安全。由于Digest Authentication当前不被广泛使用，servlet containers不要求支持它但是鼓励去支持它。

　　七、HTTPS Client Authentication

　　使用HTTPS（HTTP over SSL）的终端用户验证是一种严格非验证机制。这种机制要求用户去处理公共密钥证明（Public Key Certification PKC）。当前，PKCs在e-commerce应用中是有用的。不适应J2EE的servlet containers不要求支持HTTPS协议。

　　八、Server Tracking of Authentication Information

　　就像映射在角色中的安全标识一样，运行环境是环境的说明而不是应用的说明。

　　1．在web application的发布环境创建一个登录机制和策略。
　　2．对发布在同一个container的application能够使用同样的验证信息来代表这些application的principal。
　　3．仅仅当通过安全策略域时要求用户重新验证。

　　因此，一个servlet container要求在container层来跟踪这些验证信息，而不是在application层。允许一个经验证的用户拒绝一个使用其它资源的application，这些是通过受同样安全性标识限制的container管理的。