Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protect against security exploits via system identifier in DTD declaration [SPR-11768] #16390

spring-issuemaster opened this issue May 8, 2014 · 4 comments


Copy link

@spring-issuemaster spring-issuemaster commented May 8, 2014

Rossen Stoyanchev opened SPR-11768 and commented

A DTD declaration contains a system identifier, which can be exploited for example to scan for valid URLs gauged by the response time (quick response=valid, slower response=not valid) or can potentially be further combined with other vulnerabilities where simply accessing a URL can have side effects.

Example DTD declaration:


Affects: 3.2.8, 4.0.4


Backported to: 3.2.9

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 22, 2014

David Jorm commented

I emailed the below to on 2014-06-17 and 2014-07-11, and received no reply.

While reviewing the advisory for this issue:

I noticed that the patch commit for 3.2.9:


Does not address external parameter entities. The initial bug for CVE-2013-4152:


Notes advice from the OWASP XXE guide, which until I edited it in June, contained no guidance on disabling external parameter entity resolution. It looks like this is not disabled in any of the spring-framework code:

$ git clone
$ cd spring-framework
$ grep -R parameter-ent *
Binary file gradle/jdiff/xerces.jar matches

That said, I am unable to exploit this issue on 3.2.9, as the CVE-2014-0225 patch disables entity resolution entirely:


A side-affect of this is that it also blocks parameter entity attacks. I have been able to reproduce a full XXE attack against 3.2.8. This attack can exfiltrate data using only parameter entities, as per the technique shown on page 15:

I think that either this flaw needs its own CVE ID, or the description and severity rating of CVE-2014-0225 should be expanded to state that full XXE attacks are possible in unpatched versions of the spring framework, not just server side request forgery.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 14, 2014

Nebula commented

XEE,my papers ,Without this scene, a small hazard(spring mvc JAXB xml to pojo unMarshaller)

DTD can also XEE , Can form many types of security vulnerabilities,For example: XXE,SSRF(Server-side Request Forgery,for example: http ,ftp Protocol SSRF),DoS....,Fix one is enough.

"not just server side request forgery." ,This is not right, for large application vulnerability risks SSRF than XXE (For example:cloud application's internal network).

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 15, 2014

Nebula commented

XEE ---> XXE

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 15, 2014

Nebula commented

Because the request is initiated by the current application, so it can be used to bypass the front-end WAF.

Use very much, not limited to those

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.