javajsessionid劫持解决方案

java,jsessionid劫持解决方案
篇一：会话劫持防范
目录
Session 会话劫持 ................................................ ................................................... ..................... 1 模拟会话劫持 ................................................ ................................................. 错误！未定义书签。

防范措施................................................. ................................................... ..... 错误！未定义书签。

(1)设置 httponly
(2)session + token验证
(3)CAS校验
Session 会话劫持
会话标识是随机数据的唯一字符串,一般来说由数字和字符组成,这个字符串由web应用生成并通过cookie的方
式发送给用户。

在会话标识被发送之后,每个用户发出的请求都在其它请求中包含了该应用发送给他的会话标识。

通过使用会话标识,web应用能够识别不同的用户,区分并发的请求和及时追踪用户。

会话标识是首要的攻击目标,因为成功的捕获并重演会话标识可以为攻击者提供易受攻击web应用的当即认证。

根据窃取到的ID所属用户的访问权限,攻击者可以像普通用户,甚至是特权用户一样登录网站,并访问各种隐私数据
模拟会话劫持
我们正常地登录一个网站，登录的用户名是admin，记录好登录后的JSESSIONID
我们打开另一个浏览器Firefox，我们尝试访问一个私密链接：http://localhost/ puzzlemall/private/，这时浏览器会提示我们登录。

这说明这个链接需要登录以后才能观看
打开WebScrab并开启Proxy中的“Intercept requests”功能，并把Firefox的代理设置成WebScrab的IP和端口（8008），然后再次访问这个私密链接，这时WebScrab会截获这个请求，然后修改JSESSIONID为上面admin用户的JSESSIONID
这时我们会发现进入了admin用户的个人信息（profile）页面。

这说明我们成功地以admin用户的身份进行了登录。

当然了，这个例子只是一个会话劫持的模拟，在实际的网络中，JSESSIONID往往是通过XSS泄露出去的（或者没有走安全的协议而被嗅探）
防范措施
(1)设置 httponly，可以防止其他人和脚本获取到session HttpOnly标识是一个可选的、避免利用XSS （Cross-Site Scripting)来获取session cookie的标识。

XSS攻击最常见一个的目标是通过获取的session cookie来劫持受害者的session；使用HttpOnly标识是一种很有用的保护机制。

可以人工设置这些参数，如果在Servlet3或者更新的环境,tomcat7中开发，只需要在简单的配置就能实现这种效果：
cookie-config
>
true
true
true
兼容 Java EE 的容器，如 Tomcat 7，那么 Cookie 类已经有了setHttpOnly 的方法来使用HttpOnly 的Cookie 属性
(2)session + token验证，不仅验证sesion还要验证自己的token
实现原理：一致性。

jsp生成表单时，在表单中插入一个隐藏字段，该字段就是保存在页面端的token字符串，同时把该字符串存入session中。

等到用户提交表单时，会一并提交该隐藏的token字符串。

在服务器端，查看下是否在session中含有与该token字符串相等的字符串。

如果有，那么表明是第一次提交该表单，然后删除存放于session端
的token字符串，再做正常业务逻辑流程；如果没有，那么表示该页面不正常提交，做非正常流程处理，可以警告提示也可以什么也不做。

Token主类
文件：
jsp页面端
表单包含隐藏的token字符串:
" value="">
在Server端action中进行检验
if(((_STRING_NAME), ())){
//进行正常业务流程
}
else{
//进行进行异常处理流程
}
(3)CAS校验
CAS 基础协议
CAS Client 与受保护的客户端应用部署在一起，以Filter 方式保护受保护的资源。

对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。

用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。

在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。

协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行Ticket 验证的过程对于用户是透明的。

(详解)
添加cas-client的jar包
下载cas-client，地址：
/retype/zoom/a28234f9647d27284b7351dd?pn=5&x=0&y=7& raww=893&rawh=355&o=png_6_0_0_0_0_0_0__&type=pic&ai mh=&md5sum=5d95fe446465b8d4a3454ea14e96c52c&sign=fc 017c4cc2&zoom=&png=120508-156182&jpg=2596-2596" target="_blank">点此查看
HttpServletRequest request = (HttpServletRequest)servletRequest; HttpServletResponse response = (HttpServletResponse)servletResponse; HttpSession session = (); //在session中自定义一个参数，以它来校验是否完成过自动登陆Object user_login = (AURORA_USER_LOGIN); if (user_login != null){ throws IOException, ServletException {
篇二：JAVA WEB高并发解决方案
java处理高并发高负载类网站中数据库的设计方法（java教程,java处理大量数据，java高负载数据）一：高并发高负载类网站关注点之数据库没错,首先是数据库,这是大多数应用所面临的首个SPOF。

尤其是的应用，数据库的响应是首先要解决的。

一般来说MySQL是最常用的，可能最初是一个mysql
主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。

常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。

我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。

之所以用2个M，是保证M不会又成为系统的SPOF。

Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。

以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。

你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，从业务层面上进行分区。

最简单的，以用户数据为例。

根据一定的切分方式，比如id，切分到不同的数据库集群去。

全局数据库用于meta数据的查询。

缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。

每个cluster可以用m-m方式，或者m-m-slaves方式。

这是一个可以扩展的结构，随着负载的增加，你可以简单的
增加新的mysql cluster进去。

需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。

如果你有30台以上的mysql数据库在跑就明白我的意思了。

4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的链接池经常出问题。

二：高并发高负载网站的系统架构之HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化
/shtml/XX07/的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。

但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现
的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求高并发。

网站HTML静态化解决方案
当一个Servlet资源请求到达WEB服务器之后我们会填充指定的JSP页面来响应请求:
HTTP请求---Web服务器---Servlet--业务逻辑处理--
访问数据--填充JSP--响应请求
HTML静态化之后:
HTTP请求---Web服务器---Servlet--HTML--响应请求
静态访求如下
Servlet:
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
if(("chapterId") != null){
String chapterFileName =
"bookChapterRead_"+("chapterId")+".html";
String chapterFilePath = getServletContext().getRealPath("/") + chapterFileName; File chapterFile = new File(chapterFilePath);
if(()){(chapterFileName);return;}//如果有这个文件就告诉浏览器转向
INovelChapterBiznovelChapterBiz = new
NovelChapterBizImpl();
NovelChapternovelChapter =
((("chapterId")));//章节信息
intlastPageId =
(().getId(),
());
intnextPageId =
(().getId(),
());
("novelChapter", novelChapter);
("lastPageId", lastPageId);
("nextPageId", nextPageId);
new CreateStaticHTMLPage().createStaticHTMLPage(request, response, getServletContext(),
chapterFileName, chapterFilePath, "/");
}
}
生成HTML静态页面的类: package ;
import ;
import ;
import ;
import ;
import ;
import ;
import ;
import ;
import ;
import ;
import ;
import ;
/**
* 创建HTML静态页面
* 功能：创建HTML静态页面
* 时间：XX年1011日
* 地点：home
* @author mavk
*
*/
public class CreateStaticHTMLPage {
/**
* 生成静态HTML页面的方法
* @param request 请求对象
* @param response 响应对象
* @paramservletContext Servlet上下文
* @paramfileName文件名称
* @paramfileFullPath文件完整路径
* @paramjspPath需要生成静态文件的JSP路径(相对即可)
* @throws IOException
* @throws ServletException
*/
public void createStaticHTMLPage(HttpServletRequest request,
HttpServletResponseresponse,ServletContextservletCo ntext,StringfileName,StringfileFullPath,StringjspPa th) throws ServletException, IOException{
("text/html;charset=gb2312");//设置HTML结果流编码(即HTML文件编码)
RequestDispatcherrd = (jspPath);//得到JSP资源
final ByteArrayOutputStreambyteArrayOutputStream = new
ByteArrayOutputStream();//用于从ServletOutputStream中接收资源
final ServletOutputStreamservletOuputStream = new ServletOutputStream(){//用于从HttpServletResponse中接收资源
public void write(byte[] b, intoff,intlen){
(b, off, len);
}
public void write(int b){
(b);
}
};
final PrintWriterprintWriter = new PrintWriter(new
OutputStreamWriter(byteArrayOutputStream));//把转换字节流转换成字符流
HttpServletResponsehttpServletResponse = new
HttpServletResponseWrapper(response){//用于从response获取结果流资源(重写了两个方法)
public ServletOutputStreamgetOutputStream(){
篇三：统一认证高并发优化过程
统一认证优化过程
Edited By Bruce Bob
统一认证是整个系统的入口，所以，统一认证对于大
用户量下的并发处理能力直接关系到其他所有系统的使用。

我这里对统一认证高并发优化过程做一个整理。

希望对以后其他的工程的集群不是也能提供一定的借鉴经验。

因为我对统一认证的程序还比较有信心，我们首先直接采用了nginx+tomcat双机集群进行并发300的测试。

测试结果惨不忍睹。

然后果断采用单机tomcat先进行测试。

主要测试tomcat在linux下并发能力。

但是，在linux下测试结果依然惨不忍睹。

在测试的过程中，主要出现以下错误
(18): Error -26374: The above "not found" error(s) may be explained by header and body byte counts being 230 and 0, respectively.
(18): Error -26377: No match found for the requested parameter "PeopleSoftJSessionID3". Check whether the requested boundaries exist in the response data. Also, if the data you want to save exceeds 1024 bytes, use web_set_max_html_param_len to increase the parameter size
(18): Error -27791: Server "" has shut down the
connection prematurely
其中，27791和 26377错误非常多。

在网上找了相关的解决方案之后，发现，有可能是loadrunner的问题。

可能是脚本的自动关联出现了问题。

因为我是做开发的，对loadrunner不熟悉，同测试部门的同事讨论之后，测试部的同事对测试的录制脚本进行了更改。

然后继续进行测试，测试情况好多了。

基本没有再出现这两个错误。

测试并发100 勉强通过。

整个登录流程大约需要4s。

此时虚拟机的配置参数是：
JAVA_OPTS="-Xms256m -Xmx512m -Xss1024K -XX:PermSize=128m
-XX:MaxPermSize=256m"
当我们采用并发150进行测试时，完全不能通过。

用户数量增加到30左右就开始出错。

之前并发100是没有问题的。

但这里怎么到50就出现大量的错误，都是服务器没有响应。

后来查看tomcat相关日志，出现的错误时这样的：
: unable to create new native thread 凭借以往的经验，直接增大虚拟机内存配置。

接着进行测试，结果测试的结果更加不理想，到了30左右就出现问题。

配置如下：
JAVA_OPTS="-Xms600m -Xmx1500m -Xss20m -XX:PermSize=300m
-XX:MaxPermSize=600m"
后来进行查询，发现了问题的所在。

原来对于一般的内存泄漏导致的堆栈溢出，通常的错误信息主要有以下几种。

1. : Java heap space
2. : PermGen space
3. : Requested array size exceeds VM limit
4. : (Native method)
分析种的日志信息，得知是无法创建本地线程所致的问题。

也就是说在压力环境下拥有大量的线程，或者本地内存耗尽时，企图创建新的线程时抛出。

而系统能创建的线程数的计算公式如下：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
MaxProcessMemory 指的是一个进程的最大内存
JVMMemory JVM内存
ReservedOsMemory 保留的操作系统内存
ThreadStackSize 线程栈的大小
所以，如果配置的虚拟机参数存在，问题。

会出现配置的内存越大，所能创建的进程（线程）越少的情况。

再次对tomcat进行优化，配置虚拟机参数如下。

：
JAVA_OPTS=-server -Xms1024m -Xmx1024m -XX:PermSize=128M
-XX:MaxPermSize=256m -XX:MaxNewSize=256m
问题解决。

继续测试并发到100的情况。

结果依然不通过，主要错误还是服务器500错误。

查看服务器日志，出现的问题是这样的：
严重: () for servlet cas threw exception
: Timeout waiting for idle object
at
(:825)
其实就是从超时等待一个对象。

程序里采用池化技术的就是数据库连接池了。

查看文件
=50
=10
=XX
果然，并发100来测试，而服务器的最大连接才50，那出现从池中取对象时超时的现象也不足为奇了。

调整如下：=100
=20
测试通过。

测试结果如下：
可以看到相比第一次测试结果，性能已经得到大幅的优化。

这个时候，数据库服务器采用的是sqlserver XX.因为系统硬件限制，在进行压力测试的情况下，cpu的使用率达到90%+。

所以，数据库在这里应该是系统性能的一个瓶颈。

更换将数据库换到一台硬件条件相对好一些的机器上。