一、jsp的生命流程：
因为了解了.jsp的生命流程之后,我觉得它存在某些设计上的缺陷!下边先来简单的解释一下.jsp文件的生命流程吧!.jsp文件有它特殊的书写规范: 这些是它特殊的书写方式,为什么要规定这样写.jsp文件呢?因为它的生命流程决定了这一切。.jsp文件在被请求后不是直接的被解释器解释，然后执行。而是当它第一次被请求时，首先将它翻译为.java文件，然后在经过编译器编译，缓存在特定的目录中。下一个同样的请求将直接把缓存的结果返回给用户。 有浏览过.jsp页面的朋友可能会有这样的感觉：“第一次请求的时候，速度明显比以后的请求慢”！这就是在执行一个编译的过程。以前，我总试图通过特殊的请求阻止.jsp被翻译为.java。也一再试图通过特殊的请求阻止编译器编译.java文件。但经过思考，发现这个流程中本来就存在问题，让攻击者有机可乘！
二、通过特殊的请求达到攻击.jsp文件的效果：
大家了解了“.jsp”生命的流程后，不知道是否感觉.jsp被调用最后显示的这个过程中，每一个步骤都有问题待于我们去发现呢？首先，我们可能通过特殊的请求造成.jsp文件不被翻译为.java文件。http://target/index.JSP 这是一个典型的例子,它没有被翻译，而是直接的通过WEB SERVER将源代码泄露出来。第二，我们可以通过特殊的请求造成.java文件不被编译为.class文件。http://target/hacker/../index.jsp 这是我前几天出的安全公告上使用的办法,hacker这个目录根本不存在，按照http的格式来说这个请求的目的是找/index.jsp，因为这个hacker/后跟了..其实就是“..”应该退回到上级目录的，但因为.jsp的翻译器发现它是个.jsp文件，所以将请求的目录一并翻译（也就是java中的package）package _hacker__2e_.index_jsp。这样的打包方法明显会出错，所以泄露.java文件就很正常了。
第三，我们今天讨论的关键。
大家试想，如果前两步都成功了，现在该到把.java文件编译成.class了吧！那如果编译成.class的时候出问题呢？我的意思是生成了一个坏损的.class文件。再加上请求“.jsp”的时候,首先会判断缓存中是否存有此请求的文件，如果有，则直接从缓存中读出。也就是说缓存中的.class文件的内容是坏损的话，出来的页面当然也就是坏损的了！