Comments by CdnSecurityEngineer (Top 23 by date)

That's more or less what I was doing. However the code I posted was just debugging code to ensure that everything was functioning correctly. Once I had the bugs worked out I changed it to dump the correct process that I wanted.

Well what debugging have you done? do you have any idea/where how this is failing? I am suspecting that if your call to WScript.CreateObject("MSXML2.ServerXMLHTTP"); if this call is failing, you're going to throw an error before you enter your try.

The other odd thing, is where is localhost resolving too? A browser would resolve that to the local user's computer. Are you sure your user is creating data in the database when they hit this page?

IS port 51611 open on your server?

When you test this are you testing from the server? OR from a client separate and away from the server?

It also seems weird that you're using the GET method to send data back to the server, a WebMethod and a POST, or a Webservice (POST) WebAPI, depending on which version of ASP.NET you're using would be more logical.

I've worked in a similar environment, I am not sure if you, want to contact me directly to avoid divulging to much information. You can contact me at Chris AT howellsonline.ca

There are a ton of applications which do that sort of thing. The difficulty you have to remember is that, with two monitors, interacting with the same application, you're going to have users from 1 monitor, potentially interfering with users from another monitor. Vice Versa, I am not sure what the backend logic of your application is like. However you might encounter, race conditions etc.

However, if that's your use case, why not make it a web app? Take your backend logic code them into a dll, role your forms into ASP.NET webforms or MVC. Slap some UI on there and just point to different urls in your web app?

What browsers are you using, does it work in one browser and not an another.

Ok. So you were correct, I was considering the wrong address.
wt.ReadMemorySpecific(str.c_str(), str.length());
or your solution will also work.

So what would be your suggestion? I am using VS2012, I just need to get this POC working.

OK, lets assume, the code is looking at the wrong address. How would you change this function call wt.ReadMemorySpecific(&str, str.length()); to make it point at the right address. str.c_str()?

Wouldn't reading the string, prevent the compile from optimizing that ?

OK.... Sure but when you, consider virtual memory allocation. I need to pass the address of the internal buffer, to the function that's reading it. I can't print, stop the the program and then adjust the address I wish for it to read from. Even if I did char* pFoo = "str" and I pass pFoo I am passing a pointer to the memory that contains "str", right??? I still don't get the "str" back.

Wouldn't reading the string, prevent the compile from optimizing that ?

I know this. However the specific vulnerability I am targeting a demonstration for relies on the DOCTYPE & DTD processing. Hence why I want to get this example working, so I can make a case not to load and process our XML in such a fashion.

I think you didn't really understand or solve my question. My question was specifically how do I get xml document to load using XmlDocument to Load. Given the DTD attached. What I specifically want to konw, is why when I do XmlDocument.Load. I don't get entity expansion, can you answer that?

I don't have time to give you the step by step. However, if you do this correctly... I know that this works.

This Blog post works.

I think there are people, like security engineers ;), whom do this analysis for a price. You're asking some detailed questions here and analysis, based on a description. It's real easy to describe how something is supposed to work, and say is it secure? Well perhaps the design is secure but the implementation can be anything but. Therefore it's really difficult to truly understand what you're trying to accomplish here and what you're after. I'd be more then happy to discuss in further detail and help you out if you're interested.

Hey If you wouldn't mind accepting my answer if you found it helpful!

Unfortunately not.

That would break the "sandboxing" that Microsoft had put in place, if that were possible all you'd have to do is write a vulnerable desktop app and get the user to click it via Metro. Which would then defeat the "security" they've put in place.

Its always good to Dog Food (Use your own) API that's the way it gets flushed out and improved upon.

Even with a well thoughtful API that's well designed you can control the cost of maintaining for 3rd parties.

The most obvious API method is to bundle up a bunch of dlls and distribute that accordingly. Other methods that can help control the cost of an actual API would be something like Web Services. But then you would have to host them some where. Even distributing a bunch of dll's to 3rd parties isn't a costly solution. You just need to be sure to design your interfaces well and version them when appropriate. Then as you start to End of Life some functionality be sure to update your 3rd parties by using compile time symbols, release notes etc.

If you like my answer please accept it!
Cheers,
CdnSecurityEngineer