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?
Related
I've read online that you shouldn't update your database with GET requests for the following reasons:
GET request is idempotent and safe
violates HTTP spec
should always read data from a server-database
Let's say that we have build a URL Shortener service. When someone clicks on the link or paste it at the browser's address bar it will be a GET request.
So, if I want to update, on my database, the stats of a shortened link every time it's been clicked, how can I do this if GET requests are idempotent?
The only way I can think of is by calling a PUT request inside the server's side code that handles the GET request.
Is this a good practice or is there a better way to do this?
It seems as you're mixing up a few things here.
While you shouldn't use GET requests to transfer sensitive data (as it is shown in the request URL and most likely logged somewhere in between), there is nothing wrong with using them in your use case. You are only updating a variable serverside.
Just keep in mind that the request parameter are stored in the URL when using GET requests and you should be ok.
I'm working on a small web application, and I'm trying to decide if I should make the effort to emit semantically appropriate HTTP status codes from within the application.
I mean, it makes sense for the web server itself to emit proper response codes. 500 Internal Server Error for a misconfigured Apache or 404 Not Found for a missing index.php or whatever all make sense, since there's nothing else the server can really do.
It also makes sense to manipulate the browser with 303 See Other or other HTTP mechanisms which actually produce behavior.
But if all that happened is a missing GET parameter, for example, is there any reason to go out of my way to return 400 Bad Request? Or how about 404 Not Found, if my application is handling all the routing by itself? From what I can tell there isn't any behavior associated with either of those error codes.
My general opinion: provide codes if the code provides actionable data for the user.
If all you're doing is presenting content, then in most cases I think it's less important. If YouTube fails to load a video, I mostly care about the fact that I can't watch my video. That it failed with a 418 status might be intellectually interesting, but it doesn't really provide me with any helpful information (Even assuming a non-silly failure code).
On the other hand, if you're allowing some kind of user interaction with a server, then the codes become much more important. I might actually care about why my request failed, because I'm now in a position to do something about it.
However, there are some codes that are actionable. 410 Gone for example: If my request failed for that reason, but I just got back a generic "Stuff Broke" message, I'd probably repeat the request a bunch of times, get nowhere, and give up in frustration. Knowing that the thing I'm looking for doesn't exist is a pretty useful thing for me to know.
I think its very important for a web service to respond with appropriate codes as sometime the developer using the service might not know whats wrong or why the app stopped working unless he views the status code.
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.
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 ?
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().