Can Failure to Access the URL in an XML Schema or Document Cause my Application to Fail? - asp.net

I'm usng this: http://schemas.microsoft.com/cdo/configuration/smtpauthenticate
The schema is down? My software doesn't work anymore. Gives me a message: Can't access to CDO Message. I'm using Framework 1.1 with mail send authentication and failed.
Anyone have solution?

This is a reference name, not a resolvable URI. It's just used as a string representing some value, and your software doesn't actually fetch anything from there.
URIs are used as names because they are convenient, but it's often confusing because it appears that there should be something at the other end.
There should be more inner exceptions detail that explains the cause of the problem; could you post those?
Try following the instructions here for some possible solutions.

Just to be very clear: those things in an XML document that look like a URL, and that you see in:
xmlns="http://schemas.microsoft.com/cdo/configuration/smtpauthenticate"
or
xmlns:cdo="http://schemas.microsoft.com/cdo/configuration/smtpauthenticate"
Those are not URLs. They do not mean that .NET is going to access a location on the Internet when you are using the document. In particular, it is impossible for one of these things (which are called XML Namespaces, by the way), to be the cause of your problem.
As lavinio said above, post the complete exception and maybe you'll get some help. You should put a try/catch block around the code having the problem, catch the exception in, for instance, "ex", then post the result of ex.ToString().

Related

URL manipulation always returns a 200:OK in meteor - getting flagged as violation in OWASP-ZAP

I ran OWASP ZAP and the tool threw up a high vulnerability for possible SQL injection issue. Although we know for sure we do not use any sql databases as part of our application stack, I poked around and have have a few questions.
The payload that detected this “vulnerability” was as below:
https://demo.meteor.app/sockjs/info?cb=n6_udji55a+AND+7843%3D8180--+UFVTsdsds
Running this on the browser, I get a response:
{"websocket":true,"origins":["*:*"],"cookie_needed":false,"entropy":3440653497}
I am able to go ahead and make any sort of manipulations to what comes after the cb= part and I still get the same response. I believe this is what has tricked the tool to flag this as vulnerability - where in it injected a -- with some characters and still managed to get a proper response.
How can I make sure that changing the URL parameter to something that does not exist, returns a 404 or a forbidden message?
Along the same lines, when I try to do a GET (or simply a browser call) for:
https://demo.meteor.app/packages/accounts-base.js?hash=13rhofnjarehwofnje
I get the auto generated JS file for accounts-base.js.
If I manipulate the hash= value, I still get the same accounts-base.js file rendered. Shouldn’t it render a 404? If not, what role does the hash play? I feel that the vulnerability testing tool is flagging such URL based manipulations wrongly and ascertaining that there is some vulnerability with the application.
Summarizing my question:
How do I make sure that manipulating the URL gives me a 404 or at the very least, forbidden message instead of always giving a 200:ok in a meteor application?

RESTful PUT if not exists?

Let's say I'm creating a RESTful interface, and I want to upload a resource using PUT to /resources/{id}. But I only want to be upload the thing if it hasn't been uploaded before.
I realize that PUT should be idempotent, so if I PUT something twice to the same URL it should succeed both times, right?
I also understand that I could use HEAD on an existing resource, and then use an ETag to in my PUT to ensure that the resource hasn't been modified since I last checked.
But how can I ensure that I only upload a thing if the thing doesn't already exist? That is, how can I make sure I don't step on someone else's thing?
I realize that PUT should be idempotent, so if I PUT something twice
to the same URL it should succeed both times right?
Correct.
But how can I ensure that I only upload a thing if the thing doesn't
already exist? That is, how can I make sure I don't step on someone
else's thing?
Don't use a HEAD call. Make a PUT call using the header If-None-Match: *. This will instruct the server to only perform the operation if no current entity exists, as detailed in RFC 2616 paragraph 3.
See http://greenbytes.de/tech/webdav/rfc7232.html#rfc.section.3.2.p.7:
"If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation (Section 4.2.1 of [RFC7231]). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation for the target resource."

CRM 2011: Using Organization Service returns metadata reference issue

I'm using the Organization Service URI to upload documents to our SharePoint site from notes and attachments. I'm using the code found here and all is working apart from where i set the organizationURI. I get an error of "metadata contains a reference that cannot be resolved". I have tried retyping the link in and everything i can think of but i always get this error.
The strange thing is that this was working a couple of days ago just fine, but when i tried it the next morning it refused to work and now wont do anything at all. Before this error i have now i was getting an error saying that the URI scheme is not valid. I don't know what could have caused this to stop working but i've tried all i can think of and need some help.
Thanks
EDIT: The error message has changed to "A proxy type with the name account has been defined by another assembly". Still not sure what it means, but i'm hoping this might be easier to fix
I'm not sure if this is the actual fix for this problem but i tried this and it seemed to work. So either it is the answer or i was just lucky and something else changed too, but anyway...
What i did was to change the way that i was connecting to the organization service. Before i was using user credentials, organization URI and home realm uri together to get the OrganisationServiceProxy in the form of OrganizationServiceProxy orgService = new OrganizationServiceProxy(organizationUri, homeRealmUri, cred, null);.
Now i'm using a longer method of first setting the discovery service with user credentials. Then together with them i set the discovery service proxy, which is then authenticated. Then i simply use a RetrueveOrganizationRequest / Response to get the organization service which i can then use in place of the original.
Hope that makes sense to people but if anyone wants i can put some code up showing what i did.

Why is using a HTTP GET to update state on the server in a RESTful call incorrect?

OK, I know already all the reasons on paper why I should not use a HTTP GET when making a RESTful call to update the state of something on the server. Thus returning possibly different data each time. And I know this is wrong for the following 'on paper' reasons:
HTTP GET calls should be idempotent
N > 0 calls should always GET the same data back
Violates HTTP spec
HTTP GET call is typically read-only
And I am sure there are more reasons. But I need a concrete simple example for justification other than "Well, that violates the HTTP Spec!". ...or at least I am hoping for one. I have also already read the following which are more along the lines of the list above: Does it violate the RESTful when I write stuff to the server on a GET call? &
HTTP POST with URL query parameters -- good idea or not?
For example, can someone justify the above and why it is wrong/bad practice/incorrect to use a HTTP GET say with the following RESTful call
"MyRESTService/GetCurrentRecords?UpdateRecordID=5&AddToTotalAmount=10"
I know it's wrong, but hopefully it will help provide an example to answer my original question. So the above would update recordID = 5 with AddToTotalAmount = 10 and then return the updated records. I know a POST should be used, but let's say I did use a GET.
How exactly and to answer my question does or can this cause an actual problem? Other than all the violations from the above bullet list, how can using a HTTP GET to do the above cause some real issue? Too many times I come into a scenario where I can justify things with "Because the doc said so", but I need justification and a better understanding on this one.
Thanks!
The practical case where you will have a problem is that the HTTP GET is often retried in the event of a failure by the HTTP implementation. So you can in real life get situations where the same GET is received multiple times by the server. If your update is idempotent (which yours is), then there will be no problem, but if it's not idempotent (like adding some value to an amount for example), then you could get multiple (undesired) updates.
HTTP POST is never retried, so you would never have this problem.
If some form of search engine spiders your site it could change your data unintentionally.
This happened in the past with Google's Desktop Search that caused people to lose data because people had implemented delete operations as GETs.
Here is an important reason that GETs should be idempotent and not be used for updating state on the server in regards to Cross Site Request Forgery Attacks. From the book: Professional ASP.NET MVC 3
Idempotent GETs
Big word, for sure — but it’s a simple concept. If an
operation is idempotent, it can be executed multiple times without
changing the result. In general, a good rule of thumb is that you can
prevent a whole class of CSRF attacks by only changing things in your
DB or on your site by using POST. This means Registration, Logout,
Login, and so forth. At the very least, this limits the confused
deputy attacks somewhat.
One more problem is there. If GET method is used , data is sent in the URL itself . In web server's logs , this data gets saved somewhere in the server along with the request path. Now suppose that if someone has access to/reads those log files , your data (can be user id , passwords , key words , tokens etc. ) gets revealed . This is dangerous and has to be taken care of .
In server's log file, headers and body are not logged but request path is . So , in POST method where data is sent in body, not in request path, your data remains safe .
i think that reading this resource:
http://www.servicedesignpatterns.com/WebServiceAPIStyles could be helpful to you to make difference between message API and resource api ?

what kind of vulnerably scan is this?

Some of the 404 error logs I see on my website are obviously caused by vulnerably scanners and in most cases, I can understand what it is scanning! (and it's mainly about sql-injection)
However I've seen a couple of logs which I don't quite understand. You can see sample of the requested urls below:
http://example.com/}];this.forHtmlScript(SyntaxHighlighter.regexLib.aspScriptTags)}typeof
http://example.com/System.Web.AspNetHostingPermission,
I understand that former is somehow trying to exploit some bug in syntax highlighter I used in site (from http://alexgorbatchev.com) and the the latter is trying to make use of ASP.NET hosting bugs.
My question is:
First of all, am I right about assuming these logs as some kind of vulnerably scanner activity?
Moreover, what issue are they trying to take advantage of?
http://example.com/}];this.forHtmlScript(SyntaxHighlighter.regexLib.aspScriptTags)}typeof
I can say that the first line is possible a script error, probably you send this from javascript and looks line bug, you or any other auto-translate web program, a false redirect (a bug on the redirect)
Have nothing to exploit with this line
About the System.Web.AspNetHostingPermission
Nether this looks like exploit, to me looks like you try to make a redirect somewhere and you get a throw exception with this inside this throw System.Web.AspNetHostingPermission, and you redirect him to this throw message that starts with this System.Web.AspNetHostingPermission
look a throw message like that, you see starts the same as your directory.
System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
So to end up, they are 99.9% bugs and not exploit commands.
Last word
Check the ips that this coming from and see if its google, msn, or other indexer that usually find pages and combinations on links that you not have check. Even I think the first is from auto-translate page that try to high light some text.

Resources