当柳上原的风吹向天际的时候...

注：下例仅为学习使用，高性能的服务器例子请采用NIO方案。


可采用Telnet与上述服务器端通信，Vista上Telnet可如下方式开启:

一.嗅探器的应用范围
   嗅探器要求监听设备的物理传输介质与被监听设备的物理传输介质存在直接联系或者数据包能通过路由选择到达对方，及一个逻辑上的三方连接，具体来说有以下两种情况：
   1.监听方与通讯方位于同一物理网络，如局域网。
   2.监听方和通讯方存在路由或者接口关系，如通讯双方的同一网关，连接通讯双方的路由设备等。
   因此，嗅探技术不太可能在公共网络设备上使用，当今最普遍的嗅探行为多发生在大大小小的局域网中。

二.发生在交换式局域网内的窃听
   交换式局域网内的网络连接设备是交换机，它连接的每台计算机是独立的，交换机引入了端口的概念，它会产生一个地址表存放每台与之连接的计算机的MAC地址，除了声明为广播或者组播的报文，交换机在一般情况下是不会让其他报文出现共享式局域网那样的广播形式发送，因此即使网卡设置为混杂模式，它也接收不到发往其他计算机的数据，因为数据的目标地址会在交换机中被识别，然后有针对性的发往表中对应地址的端口。
    在这种环境中，嗅探器为了监听特定计算机的通讯，通常采取ARP欺骗行为，这时嗅探器充当了一个被监听对象与信息交换对象之间的转发者的角色，它会截获双方发给对方的信息后经过处理在发送给目的方，这时嗅探器对双方是透明的。

注：下文涉及一种Web入侵方式的古老方法，即利用Cookie冒充已登录用户。熟知此方法的朋友请退散。

我们在做Web应用时，习惯把用户信息放到Session中，而这一举措，实际上有较大的潜在危险性，如果别人知道了我们的session id,就可能利用它以我们的身份进入Web应用。因为session的数据虽然存在于服务器中，但识别客户端各自的数据还是靠存放在客户端的session Id的，如果有人以某个已登录的用户的session Id进入Web应用，那么他就会被当作那个用户，下文将展示这一过程。

首先，我们让某个用户正常登录一个位于Tomcat上的应用，注意右上角的用户名的显示：



再取得他的session Id。这一步实际上有很多途径取到，比如url中有时带有它，Struts做前端的e
Web应用就时常可见；本地cookie中可以找到它，这个用程序就能知道，用js也行（使用document.cookie）；用嗅探器也可以获得它，这个嗅探器可以放在想冒充用户的机器或是网关上。下面使用了TCPMon得到其session id（具体使用方法请参考 http://www.blogjava.net/heyang/archive/2010/12/10/340294.html）。

上面高亮的文字部分就是“关羽”这个用户的session id。

现在，url “http://localhost:8080/ProjectManager/GotoModifyUserPage.do” 和session id“4DC291FC36B2392BE440F70E5B3AA49D” 我们已经得到，接下来就是用它们来进入web应用了。

一般的浏览器没有可供输入 session id的地方，但从原理来看我们知道这并不复杂，因为http是基于文本的，只要有工具能把Url和cookie捏合起来成文本并发送就可以了，WebTool就是这样的一款工具，你可以从http://www.hackline.net/a/soft/tools/2010/0603/4198.html  来获得它。

得到下载文件解开包，执行里面的WebTool 4.2.exe，点击其菜单“设置”-->“自定义cookie浏览”，使其成为勾选状态，然后在地址栏输入http://localhost:8080/ProjectManager/GotoModifyUserPage.do，左下方的cookie处输入4DC291FC36B2392BE440F70E5B3AA49D，然后点击右上方的“Get”按钮，你将看到以下画面：


好了，看看其右上方把，用户名“关羽”已经显示出来了。我们这会不用得知关羽的密码也能以他的身份开始操作了，这就是冒充session id做到的。

好了，感谢您看到这里。可见，常规Web应用还是比较脆弱的，但这种入侵方式也好防范，将协议改成改成https就可以了（请参考 http://www.blogjava.net/heyang/archive/2010/12/13/340500.html）。另希望有人不要把上文的技巧用到不该用的地方，去动本不该属于自己的东西是危险而徒劳的。

注：以下文字还是老调重弹，对在Tomcat上配置https熟悉的朋友就不要浪费时间了，另喜欢英语的朋友请直接到https://localhost:8443/docs/ssl-howto.html或是http://localhost:8080/docs/ssl-howto.html查看原文档。

给Tomcat配置https只有简单的几个步骤，比较容易完成的：
1.首先，用keytool工具生成证书。
  keytool工具是jdk自带的，您可以从JAVA_HOME/bin下找到它。
  在命令行Command中，您可以输入以下命令来生成认证证书：
  C:\jdk1.6.0_13\bin>keytool -genkey -alias tomcat -keyalg RSA -keystore c:\tomcat.keystore
  注意上方命令两个加粗的文字，前者是我的JAVA_HOME/bin，后者是证书的文件名，您需要根据您的实际情况进行调整。

2.输入必要的数据。
  在命令行窗口输入上面的指令后，控制台还会询问您一些信息如名字，城市，国家等，这些随便写就成了，但有一个地方不能胡来，就是密码。注意它最要和Tomcat的admin用户登录密码保持一致，也就是说问你输入密码的时候你要使用Tomcat的admin的密码（我自己的是123456，如果不记得了请查看您的TOMCAT_HOME/conf/tomcat-users.xml文件）。最后，当控制台问你是否要和Tomcat的admin是一个密码时，回车即可。

3.修改Tomcat配置文件Server.xml
如果以上手续成功,那么c:\tomcat.keystore将会被生成，接下来修改TOMCAT_HOME/conf/server.xml，找到<Connector ...    port="8443".../>这样一段，将它替换成下面的文字：
注意上述文字的粗体部分，请和您自己设定的文件及密码保持一致。

4.重启Tomcat，再以https://localhost:8443来访问Tomcat。
  注意Tomcat也有不听话的时候，有时需要重启一下计算机。
 
好了，就是这些，感谢您看到这里。

以下文字只是记录我做的一个小实验，没有代码和程序，没有兴趣者请退散。

在“用TCPMon验证Web应用的安全性隐患”中谈到，http基本就是明码，如果用嗅探器获得http数据包的话，甚多私密信息都被被截获，下面将记录这一过程。
下文中提到的嗅探器是Wireshark，这是一个优秀的免费软件，您可以从 wireshark官方网站 得到它。
下文中涉及的站点是天涯的用户登录页面（http://passport.tianya.cn/login.jsp），下面实验中要用到已经注册的用户名test_user2010及其密码t123456  .


首先，我们要知道本机的IP地址和点击登录页面的登录按钮后要向他发出http请求的机器的ip地址，前者用ipconfig就能知道，后者的话需要打开网页源码获取响应服务器的网址，再用ping获得其IP地址。请参考下图：
打开网页源码获取响应服务器的网址：


再用ping获得其IP地址：


到这里，我们知道当我们在登录页面输入用户名和密码后，本机192.168.104.173将和221.11.172.202取得联系。

第二步，我们打开Wireshark，让它开始监听网络数据包，当我们点击登录按钮并登录成功后再停止监听。

第三步，我们可以从Wireshark的监听结果中去找想要的数据，为了减小范围，我们可以在filter中输入ip.src==192.168.104.173  && http，它表示IP来源是本机IP，使用的协议是http，下面是找到的结果：


在infor一列中，书写有POST /login http/1.1 （application .....）的一行就是点击登录按钮后发出的http请求，这一行在上图中用蓝色框框起来了。

点击这一行，弹出的界面中已经把我们输入的用户名和密码都暴露出来了，上图中用红色框表示。

好了，到这里实验就做完了，它表示以Http为基础的Web世界并不安全，用户名和密码不足以保护您的私密信息，所以，很多网站也需要加强安全措施，您自己也尽量不要把隐私信息放到网上。

最后感谢您看完此文。

附：2010年12月24日的截图

很简单，程序如下：

输出如下：

下面是一个辅助的工具类：

Web应用的安全性一直有一个先天缺陷，即http基本就是明码传递，这个缺陷可以让后台做的诸多加密工作一朝崩塌，下面以一个实际例子来说明。

我们还是用TCPMon来截获http请求，看从中能否找到有用的信息，下面的Http请求来自很多网站都有的注册和登录页面。TCPMon的具体方法请参照：如何用Apache TCPMon来截获SOAP消息。

下面是用户注册页面，我们向其中输入了一点信息：

点击“提交按钮后”，我们在TCPMon中可以截获这样的内容.



下面是登录页面：


点击“登录”按钮后，TCPMon截获的内容如下：


上面两个字符串：
name=%E5%88%98%E5%A4%87&email=1@3445.5&pswd=123456&repswd=123456&brief=rteterte&submitBtn=%E6%8F%90%E4%BA%A4
name=%E5%88%98%E5%A4%87&pswd=123456&submitBtn=%E7%99%BB%E5%BD%95

已经暴露了不少信息，我们再转码一下会全部暴露出来：

输出如下：

也就是说，我们在表单中输入的内容，已经完全出现在http请求中。只要加一个网络嗅探器（sniffer）来收集网络上传递的数据报的相关信息，再加以少许处理，所有私密信息都将被发现。

注：以下是关于TCPMon的一些使用常识，如果不需要或是已经熟悉就不用往下看了。

在WebService服务器和客户机之间会传递SOAP消息，有时我们需要得到这些消息以便调试，而Apache的TCPMon可以帮助我们做到这一点。

TCPMon的下载地址在http://ws.apache.org/commons/tcpmon/download.cgi，找到Binary Distribution，
下载后会得到一个tcpmon-1.0-bin.zip的包，解开后进去\tcpmon-1.0-bin\build目录，双击tcpmon.bat就可以执行程序了。

这里有必要对tcpmon说明一下，它实际上是个代理，起一个消息转发的作用，监视的是转发出去的消息。最终，消息还是要送到具体的地址和端口，否则响应就不正确了。也就是说，TCPMon是一个消息的二传手，它的前后都应该配置正确才行。


现在我们手头有一个WebService测试客户端，一个WebService工程运行在Tomcat服务器中，这就是TCPMon的两端，我们需要把它配置进去。

首先，我们需要修改Tomcat的服务端口，你可以打开Tomcat目录下的conf目录下的server.xml文件，将Connector节点的port属性值从8080改成8088（也可以是其他端口），如下所示：
<Connector port="8088" protocol="HTTP/1.1" maxThreads="150" connectionTimeout="20000" redirectPort="8443" />
这样，Tomcat服务器就在8088端口进行监听了。

其次，我们需要让TCPMon在8080端口进行监听，并把收到的消息转发到8088端口去。我们找到刚才打开的TCPMon程序，找到admin选项卡，在listen port #：右边的文本框中写入8080，在Target HostName右边的文本框中输入127.0.0.1，在Tatget port右边的文本框中输入8088。如下图。


然后，再点击add按钮。一个名为Port 8080的选项卡会出现，这个界面将负责显示截获的SOAP消息。

接下来就可以启动客户端程序，客户端会向原来一样，向127.0.0.1所在的8080端口送出SOAP消息，而这个消息会被TCPMon截获，然后转送到127.0.0.1所在的8088端口去，然后Tomcat会收到这个SOAP消息交给负责处理的XFire Servlet，处理完的结果会通过TCPMon送回到客户端。在这个过程中，SOAP消息就被完全截获并显示在Port 8080选项卡中了。如下图：


最后，当你的SOAP消息调试结束后，别忘了吧Tomcat的端口改回到8080。

感谢您看到这里。

注：下文是关于WebService的一个概念和总结，其中的例子来自http://www.box.net/shared/cyg98xgz78 。 如果您对WebService已经熟悉就不用浪费时间了。

一.什么是Web服务？
Web服务是网络化应用程序的一种，我们可以将Web服务看成一种函数调用，只不过这个函数的实体存在于某个服务器上，而调用在客户端进行。Web服务的思想很简单，即服务器通过网络提供Web服务，其它程序可以将由Web服务器封装的功能无缝的集成到自己的程序中去。Web服务是跨平台跨语言的，它可以由多种语言创建，也可以由多种语言使用。WebService定义了一套标准的调用过程：服务器端使用WSDL来向外界描述它所提供的服务，客户端与服务器端的交互采用SOAP协议。

二.Web服务有什么益处？
处于这个信息化高度发展的世界，每个软件系统都势必要和别的软件系统进行交互，它们可能由不同语言编写运行在不同的服务器上，相互间的调用是一个很大的难题。Web服务就是为解决这些问题而诞生的，它的语言平台无关性可以和任一平台或语言的软件进行交互，这样，Web服务就可以像一座桥梁，可以连通信息化世界中的孤岛。

三.SOAP协议。
在Web服务中，服务器和客户机需要传递接收消息，这就需要对传输的数据格式采取一定的约定措施，这个约定就是SOAP协议，它的全称是简单对象访问协议（Simple Object Access Protocl）。SOAP是基于XML的消息包装器，它既包括客户端送给服务器端希望调用的类和方法的一种消息格式，也包括服务器返回数据的消息格式。有个这个协议，服务器和客户机就能明白对方想干什么。SOAP消息一般基于HTTP来传输，也可以基于其他协议。
下面是一个客户端向服务器发送的SOAP消息例子：
客户机向服务器端发送消息时，</soap:Body>中的XML包含要调用的方法和参数，如上述的getServerPublicKey。

下面是服务器反馈给客户机的SOAP消息例子：
当服务器端送回消息时，</soap:Body>中包含调用的结果，它可以是单个值，也可以是含有多个值的复杂数据类型。如上面的<ns1:out>中的节点值。

另：在调试WebService程序，想要查看SOAP消息时，可以使用Apache的TCPMon工具，具体使用方法请看http://www.blogjava.net/heyang/archive/2010/12/10/340294.html.

四.服务器端收到SOAP消息后的动作
以XFire为例，当一个来自客户端的SOPA请求送达WebService服务端时，它会先送到一个Servlet（XFireConfigurableServlet）中（请参看web.xml中的配置），然后开始解析SOAP消息，再根据配置文件services.xml找到接口com.heyang.IService和具体的实现类com.heyang.ServiceImpl中的方法，调用函数产生结果，然后再包装成SOAP消息返回。Axis的做法也是类似的。

五.WSDL
我们现在可以想到Web服务是一个对象，含有一个或多个方法。如何对一个WebService服务器能提供的方法进行说明呢？这里就要用到WSDL（Web Service Description Language），它定义了Web服务提供的可供操作的函数，具体如下：
  以上内容在浏览器中输入http://localhost:8080/XfireSample/services/hello?wsdl 可以看到。

  WSDL本身比较复杂，它主要给程序看的，利用当前大多数的Web服务工具可以生成它，而无需手工编写它。
  WSDL的主要目的在于将自己的Web服务的所有相关内容如提供服务的传输方式，服务方法接口，接口参数，服务路径等，生成相应的完全的文档，发布给使用者。使用者可以通过这个WSDL文档，创建相应的SOAP请求消息，通过HTTP传递给Web服务提供者；Web服务提供者在完成请求服务后，将SOAP返回消息传回给请求者，服务请求者再根据WSDL文档将SOAP返回消息解析成程序能够理解的内容。

六.UDDI
UDDI是Universal Description Discovery and Intergretion的缩写，是一种创建注册服务的规范，以便大家将自己的Web Service进行注册发布供使用者查找。
当服务提供者想将自己的Web Service发布，以便外部能找到其服务时，那么服务提供这可以将自己的Web Service注册到相应的UDDI商用注册网站。
UDDI并非一个必须的Web Service组件，服务方完全可以不进行UDDI的注册。因为WSDL文件中已经给出了Web Service的地址URI，外部可以通过它进行相应的Web Service调用.

七.消息服务与WebService的比较

在概念上，Web Service和消息服务它们都是传输数据到别的组件，都是使应用程序之间可以进行异步通信。
消息处理和Web Service是互补的技术，消息服务明确是一项为企业内部而不是为商业领域内的应用程序提供通信的技术，使用消息处理，企业必须与共用的传输格式达成一致，在定义应用程序之间传递的数据方面，消息具有更多的灵活性，另外，Web Service缺乏一个定义好的机制，用于确保SOAP传输和事务处理，这些是消息服务已经定义好和成熟的部分。
Web Service，是松散耦合的组件，应用程序发送请求给它进行处理和数据服务，结果返回给应用程序继续处理，传输机制是Simple Object Access Protocol（简单对象访问协议，SOAP），Web Service通过SOAP能有效的通过HTTP协议发送XML文档。Web Service具有公开性，具有快速推进的标准和大量出版物与技术文档。Web Service有潜力来连接不同的应用程序组件，把软件定义成服务而不是产品。如果应用程序是新建的，则Web Service更为合理。

八.使用Axis的WebService实现。
以上文章是针对XFire的WS实现，如果要用Axis的实现，可以参考这里 http://www.blogjava.net/heyang/archive/2009/10/10/297729.html 或 http://www.blogjava.net/heyang/archive/2009/09/29/296897.html。个人感觉XFire的方案更方便快捷，如果没有限制的话建议使用XFire实现Web Service。

好了，感谢您看到这里。

一.框架类
   1.JavaScript框架：ExtJs（http://www.sencha.com/）
   2.O/R Mapping框架：Hibernate（http://www.hibernate.org/）
   3.JavaScript框架：Jquery(http://jquery.com/)
   4.JavaScript框架：Prototype（http://www.prototypejs.org/）
   5.业务层Bean管理框架：Spring（http://www.springsource.org/）
   6.Web框架Struts1：Struts（http://struts.apache.org/）
   7.Web框架Struts2：Struts 2（http://struts.apache.org/2.x/index.html）

二.工具包类
   1.用于编码处理(Base64，DES,RSA.MD5等)的Apache Commons Codec（http://commons.apache.org/codec/）

三.开发测试工具
   1.网页测试工具：HttpUnit（http://httpunit.sourceforge.net/）
   2.Java单元测试工具：JUnit（http://www.junit.org/）
   3.网络数据包截获工具：TCPMon（http://ws.apache.org/commons/tcpmon/download.cgi）

四.服务器类


五.数据库类
   1.轻量级纯JavaSQL数据库引擎HSQLDB（http://hsqldb.org/）
   2.重量级数据库Oracle（http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html）

六.插件类
   1.用于UML图绘制的Eclipse插件Amateur（http://sourceforge.jp/projects/amateras/releases/?package_id=4435）

七.技术站点社区类
   1.中文综合技术社区CSDN社区（http://community.csdn.net/）
   2.英文综合技术站点ServerSide（http://www.theserverside.com/）

八.引擎类
   1.Java Web服务实现引擎：XFire（http://xfire.codehaus.org/）
   2.Java Web服务实现引擎：Axis2（http://axis.apache.org/axis2/java/core/download.cgi）

九.工具类
   1.网络数据包嗅探器Wireshark（http://www.wireshark.org/download.html）
   2.Web检测工具WebTool（http://www.hackline.net/a/soft/tools/2010/0603/4198.html）
   3.Office工具POI（http://poi.apache.org/）