XML "Data Leak" Error?

46 views
Skip to first unread message

Darwin Airola

unread,
Mar 26, 2015, 12:42:28 AM3/26/15
to reste...@googlegroups.com
Todd,

I have started to notice that internal data starts getting leaked when I return objects in XML format, but returning those same objects in JSON format does not have that (security) bug.

For example, when I utilize the same route:

server.regex( "/db(/(?<dbName>.*))?/function/(?<inx>[0-9]+)[/\\.]{1}(?<st>[0-9]+)[/\\.]{1}(?<et>[0-9]+)([/\\.]{1}(?<format>[a-zA-Z]{3,}))?", config.getDBController() )
      .action("
function", HttpMethod.GET )
      .action("
function", HttpMethod.POST)
      .name( "Function" ) ;


If I GET from:


This is the result, as expected:

{"c":4,"ts":12,"ai":{"hs":3,"ac":1,"MAX_S":5},"MAX_AC":5}

However, if I GET from:


This is the (erroneous) result (notice the data leaking):

<HTI>
  <c>4</c>
  <ts>12</ts>
  <ai>
    <hs>3</hs>
    <ac>1</ac>
    <MAX__S>5</MAX__S>
    <outer-class>
      <config>
        <port>4444</port>
        <ipAddr>192.168.3.9</ipAddr>
        <protocol>tcp</protocol>
        <baseUrl>jdbc:mysql://
192.168.3.9:4444/</baseUrl>
        <username>un</username>
        <password>pw</password>
      </config>
    </outer-class>
  </ai>
  <MAX__AC>5</MAX__AC>
  <outer-class reference="../ai/outer-class"/>
</HTI>


Obviously, we do not want such sensitive information leaking through.

Is this a known issue? Is there a way to work around it?

Furthermore, again, my named group enhancement to your RestExpress/core/src/java/org/restexpress/url/UrlRegex.java file is extremely beneficial, as you can see from the route definition, above, and it greatly eases the comprehensibility of the related controller method(s). If you would like me to check this in, just let me know how to do so.

Have a great day.

Take care,
Darwin


---------- Forwarded message ----------
From: Darwin Airola
Date: Tue, Mar 17, 2015 at 2:54 PM
To: Todd Fredrich


Todd,

Okay, I resolved this so that we can use named groups in our regular expressions (when defining a regular expression based route). This only required me to modify the extractParameters() method in the RestExpress/core/src/java/org/restexpress/url/UrlRegex.java file.

Would you like me to contribute those changes back to your project?

Have a great day.

Take care,
Darwin

--
P.S. For answers from יהוה, read: Answers From God.

Todd Fredrich

unread,
Mar 26, 2015, 1:19:22 PM3/26/15
to reste...@googlegroups.com
Hi Darwin,

I'm wondering how your project removes the "erroneous" data from the JSON payload. I'm guessing it's via Jackson annotations.

So here's the thing... RestExpress XML processing is provided via XStream. So you'll have to annotate your domain with XStream annotations also. Either that, or remove or null-out those properties in code.

Alternatively, which is what I'm currently leaning toward in my projects to reduce the testing burden, is to remove XML support altogether. Our production APIs have less-than 1% XML usage. So for the testing effort, it's just not worth it.  To do that, just remove the XML-specific items from your SerializationProvider in the serialization package.

Interested to know where you end up.

BTW, open to pull requests for your named group feature in the regex routes.  Just augment the unit tests and we'll be good. Much appreciated!

Thanks,
--Todd

Darwin Airola

unread,
Sep 19, 2016, 3:06:58 AM9/19/16
to RestExpress
Todd,

I took your advice and stopped supporting XML. Great call.

Also, FYI, I finally got around to checking in the regex based routes code. You can find my pull request here. I apologize that I did not contribute this, sooner, but I got put onto another project shortly after this discussion and only recently created another microservice that also needed regex routes, causing me to reincorporate the changes into your latest codebase, after which I quickly committed the changes before I got assigned to something else, again.

Furthermore, I also added a simple fix to one of your archetype build scripts, here.

Have a great week.

Take care,
Darwin
Reply all
Reply to author
Forward
0 new messages