Right now, a request sent to a valid DataPower port with an invalid URI is answered with http 500.
This has been deemed to be a security risk, and I am looking for a way to reconfigure it so that it instead causes a connection termination, or anything that wouldn't inform a possible attacker that they have found an active port.
For example: if a valid WSP URL is http://datapower:80/abc, I would like someone who tries http://datapower:80**/a** to get the same result as someone who tries http://datapower**:90/**abc.
The only way I know of to return a custom error code is through a gateway script in a Policy object, which is obviously irrelevant to wrong URI calls that don't activate a WSP/MPGW.
Is there any way to arrange this in DataPower?
Related
I have implemented a proxy extending jetty's ProxyServlet.Transparent.
However upon testing I noticed there is a difference on error messages the user sees when the server returns an error.
For example, when connecting directly to one of our application server with an invalid user credential, the server should return something more specific with instructions on the auth as we have set it this way. When connecting to the proxy server the error is in its most generic form like Authentication failed: Unauthorized
I suspect at some stage jetty checks on the server response and set the proxy response with minimal information so I am looking into the Transparent class code and its parent classes to find which method I can override to intercept the original server response and forward the information in the proxy response, assuming my understanding on these two responses are correct.
Thanks for the help.
So I made a copy of my jmx file and obfuscated the domain to include here. Be kind. I am a load testing noob. :)
I have a load testing target. I must be on the VPN to access the target's website. When connected to the VPN, my load test numbers make no sense. This is cool. I am not convinced I have the test created correctly. But what is weirder still is that when I am NOT connected to the VPN the requests receive a response. The results tree has pretty little green checkmarks (well really shield icons). But there is no way it should have been able to communicate with the server. But when I look at response body, it is a very reasonably approriate response body.
My jmx file is too big. I will try to attach it. But does anyone have an explanation for what might be going on? Or what I might have done wrong?
These "pretty little green checkmarks" doesn't mean that you're hitting the correct server, JMeter automatically treats HTTP Status Codes below 400 as successful so my expectation is that you're basically hitting some form of VPN web gateway login page or something like this and JMeter considers these redirects as successful responses.
You can inspect request and response details using View Results Tree listener and see what exact host you're hitting and what does the response say.
Going forward in order to protect yourself from these "false positive" results you can consider adding Response Assertions to your requests to ensure that response contains what it is supposed to be containing or alternatively doesn't contain errors
The following is quoted from RFC6455 - WebSocket protocol.
Servers that are not intended to process input from any web page but
only for certain sites SHOULD verify the |Origin| field is an origin
they expect. If the origin indicated is unacceptable to the server,
then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Forbidden status code.
The |Origin| header field protects from the attack cases when the
untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client
itself can contact the server and, via the mechanism of the |Origin|
header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to prevent
non-browsers from establishing connections but rather to ensure that
trusted browsers under the control of potentially malicious JavaScript
cannot fake a WebSocket handshake.
I just cannot be sure about what the 2nd paragraph means, especially the italic part. Could anyone explain it a bit? Or maybe an example.
My understanding so far is like this:
If server CAN be sure that requests DO come from Web pages, the ORIGIN header can be used to prevent access from un-welcomed Web pages.
If server CANNOT be sure that requests come from Web pages, the ORIGIN header is merely advisory.
Your understanding seem to be correct, but..
I would rephrase it - you can be sure, that javascript client will send proper origin header. You don't know what will be sent by other clients (and whether the value is correct or not).
This should prevent other pages to connect to "your" web socket endpoints (which is a big deal, imagine injected javascript somewhere on jsfiddle or some frequently visited page), but if you need to make sure that no other client will be able to connect to it, you'll need to introduce some other security measures.
I believe this is meant only as prevention of browser based "data stealing" or "DDoSing", nothing else; you can still do that by using some other client.
I have a system that logs information and sometimes find a particular IP address doing something nasty, like trying to exploit phpMyAdmin (even though it isn't even installed on the system).
When I find these offenders, I add the IP address to a block list that returns a small message whether the page exists or not and log the IP address and their query string so I can keep tabs on them.
Problem is, most of them appear to be scripts that scan, and I am still technically returning a HTTP status code of 200 with the small message. I want to be more forward with the status code, but I am not sure which one best applies.
I found the list here, and it seems that 401 or 403 best apply. Which is the best code for "banning" an IP address?
403 or 404 is best suited. See the reference for 403:
"(...) If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead."
Source: https://www.rfc-editor.org/rfc/rfc2616#section-10.4.4
For example you can return a status 403 - Forbidden and describe the reason in the response body. I'm not sure whether it is allowed to return a status code like 403 - Banned for .... In any case, innocent users are probably especially interested in the reason for the 403.
I’ve got a situation with a large internal corporate web based application running ASP.NET 3.5 on IIS6 generating 401 “Unauthorised” responses followed by 200 “Ok” responses (as profiled by Fiddler). I’m aware of why this happening (integrated auth forcing the browser to resend credentials) but I’m looking for some thoughts on how to minimise or eradicate the situation. The application in question is running in the WAN with some users experiencing latency of up to 250ms so forcing a subsequent request can have a noticeable impact on page load time, particularly when there are a number of cascading drop down lists on the pages making.
The users of the application are internal within a managed desktop environment so mechanisms to force the browser to send credentials on the first request (is this even possible?) could be possible from a deployment perspective. This would work for pages requiring the user’s identity but for resources not requiring authentication (WebResource.axd, ScriptResource.axd and some custom web services), allowing anonymous auth would be possible. I’ve looked at defining this on a per location basis in the web.config but the results were mixed (still a number of 401 responses).
I’d appreciate any guidance on a “best practice” for dealing with this situation. There are a lot of resources out there identifying the problem but none that I’ve found providing a feasible solution.
Thanks!
Edit: Resources not requiring authentication (i.e. web services used for cascading drop down lists) can be requested anonymously through adding a location entry to the web config but I'm yet to find an answer for authenticated resources.
Unfortunately this is an artifact of the HTTP NTLM authentication scheme.
In short, the browser (Internet Explorer or otherwise) doesn't know that it needs to authenticate at all until it gets bounced with a 401 response containing a WWW-Authenticate response header.
In the case of WWW-Authenticate: NTLM -- annoyingly enough -- it requires two 401 responses on a single persistent connection to complete, and this process must be repeated once the HTTP persistent connection is closed. So even if you were able to get the browser to initiate a request blindly attempting NTLM, at least one 401 response cannot be removed from the transaction.
I think your best bet would be to maximize the amount of time that persistent connections are left open when idle.
CSCRIPT.EXE c:\inetpub\adminscripts\ADSUTIL.VBS SET W3SVC/AuthPersistSingleRequest FALSE
Will reduce the amount of 401's significantly.
I believe you can convince Firefox to automatically send NTLM credentials to a whitelisted set of domains via "about:config" settings - use the "network.automatic-ntlm-auth.trusted-uris" setting. I haven't tried this myself though. I'm not sure there's any equivalent for Internet Explorer.
Unfortunately if you're using something else like Kerberos there does not seem to be a way to avoid the 401.
You may need to consider Forms Authentication if the 401-induced latency is too long. The users would have to explicitly log in, but just once. Then you could use a cookie or cookieless scheme and get a response on the first try.
I imagine that page load would be slow if you have cascading drop-downs and your initial page load populates one value that causes a POST to get the next list, set that value, another POST to get the next list again, and so on. If this is the situation, perhaps you need to populate all those drop-downs on the first round-trip rather than waiting for POST responses.
TL;DR I put HTTP header information in HTTP body
My example is in Angular, but any TypeScript/JavaScript (framework) might have the same issue.
When doing a HTTP post call to my backend API, which requires headers with the logged in user information, I added my HTTP headers where my HTTP body should be and the headers were empty.
PROBLEM
markInstructionAsCompleted(visitScheduleId: string, instructionId: number) {
return this.http.post(`${environment.apiUrl}/VisitInstructions/schedule/${visitScheduleId}/done/${instructionId}`, this.getHeaderWithAuthorization());
}
SOLUTION, notice that there's an added second argument to the HTTP post call, which is null
markInstructionAsCompleted(visitScheduleId: string, instructionId: number) {
return this.http.post(`${environment.apiUrl}/VisitInstructions/schedule/${visitScheduleId}/done/${instructionId}`, null, this.getHeaderWithAuthorization());
}