HTTP Error 403.0 - ModSecurity Action - asp.net

I m creating a code in which based on query string the URL is changing when no values are supplied in URL everything is working fine but as i supply values to URL it shows Error HTTP Error 403.0 - ModSecurity Action
Kindly suggest some solution
also the same is working fine in local problem occurs when i upload my webpage to server

I know this is an old thread, but posting the answer so that it can be helpful for others. ModSecurity is an open source, cross-platform web application firewall (WAF) module.
https://modsecurity.org/about.html
So whenever you see the 403 (ModSecurity Action), this means that the mod security firewall has blocked the request. The probable cause could be vulnerable data present in the posted data, or the it could be because of the URL posted as parameter or it could be JavaScript.
In above case, the ModSecurity might have deemed the input as SQL Injection attack and hence may have blocked it. If you look into the logs of the firewall it may give you the detailed explanation.
In my case, I was passing URL as query parameter in the request hence it was returning 403.

Related

"Post" via indy fails, while "Get" is working, using xe2, https and windows authentication

i already tried to find an answer here on nearly at any place at the web, but didn't find an answer that helped me out here - so i'm trying it here with this question:
i have to to get some information from a server in a domain, using https via indy components and the windows authentication. that's working quite fine (via IdHTTP1.Get(sURI)), the server logs are showing this (domain/user/request) and the response is always valid.
afterwards i try to post now some new values to the requested data, but this fails, since i get a "401" authenticaion error. BasicAuthentication=false, and HTTPOptions=[hoInProcessAuth,hoForceEncodeParams] via IdHTTP1.Post(sURI, Req_Json), where Req_Json is a UTF-8 encoded TStringStream. Now (and only when trying to POST) the IdHTTP1Authorization event is triggered twice, even if I do a handled=true there (read somewhere in a forum) it fails, if I do nothing there I get the same result: 401. There were some tips about the IdHTTP1SelectAuthorization event, but with that I had no luck, too.
Any ideas, where to start to get this solved? If there are any questions open, don't hesitate to ask!
p.s.: trying to post the same information via postman works correctly - so i guess it's about delphi/indy ...

Is status code 404 appropriate when a user isn't authenticated?

I've been working in web development (mainly as a backend developer) for nearly 10 years, and most services I have worked with return status 401 Unauthorized when the user is not authenticated. During a recent discussion with a colleague, they suggested that we return status 404 Not Found when a user isn't authenticated so that we don't even disclose an endpoint even exists at that URL.
I understand where they coming from, but to me it just felt wrong. This way you can't easily tell whether the failure is because the user isn't authenticated, or the URL is incorrect.
I looked at RFC7235, and it states the following:
The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists.
This follows the same argument as my colleague suggested, so should I be returning 404 Not Found for requests when a user isn't authenticated?
You can find a similar statement about 403 Forbidden status code in RFC 7231:
An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of
404 (Not Found)
So generally it is up to you and your team to decide whether to use 404 or 401 status code.
P.S.: some web security apps and tools are analyzing 404 pages to skip similar pages later. And URL structure is sometimes get analyzed as well.
So if you have some sensitive data or don't want to disclose the structure of your project to anybody - 404 Not Found is a good idea for security reasons. And you app/API becomes more difficult to reverse engineer.
The downside of this approach is that it's a bit unobvious on the client side - it will be more difficult for your clients to figure out what went wrong when it receives 404 Not Found.

Configuring CSRF Allowed Sites in Spring

I have my e-commerce website and dealing with a 3rd party payment vendor integration. I send them a URL and they're returning a POST request to it. The problem is I'm receiving 403-bad or Missing CSRF Token error.
The incoming request is as follows:
Request URL:https://mavi.local:9002/checkout/callback/secure3d?CSRFToken=425cc3ee-df74-482a-955b-c7836abff410&responseCode=0000&token=D7ED3EBA21864253AD7AA33AABB492C7FA90DDEBD7AD448D1210EF85814E077505BC8E58E1F29AC2153E600678E6545A2D87FAACF516AC3249F7D8572EA767835C89F1E370C01532F0DCCABF8ACCC7F215AE838E9B917204F1C362140E6F5E87
Request Method:POST
Status Code:403 Forbidden
Remote Address:127.0.0.1:9002
Referrer Policy:no-referrer-when-downgrade
And the initiator is:
test.masterpassturkiye.com/RedirectServer/MMIUIMasterPass_V2/s3d/bank/success?RRN=500007047967:7
I'm trying to add this url as allowed Cross Origin request in my Spring configuration.
I have tried 2 options.
Updating csrf.allowed.url.patterns setting in project.properties as follows:
csrf.allowed.url.patterns=/.*callback|.masterpass|[^/]+(/[^?])+(sop/response)$,/[^/]+(/[^?])+(merchant_callback)$,/[^/]+(/[^?])+(hop/response)$,/[^/]+(/[^?])+(language)$,/[^/]+(/[^?])+(currency)$
This regex mathces with the url but not the whole URL, I think it might be a problem, yet I'm not sure.
Inserted below item into my spring-mvc-config.xml
<util:list id="csrfAllowedUrlPatternsList" value-type="java.lang.String" >
<value>.*masterpass</value>
</util:list>
I adopted this solution from this blog post
Yet the problem with the 403 error still continues. What might be the possible problem with my configurations? Any help or idea will be great help.
I believe that your value in spring-mvc-config.xml is wrong.
Please try with /checkout/callback/secure3d since this is the Hybris URL which handles the POST request and which should not ask for a CSRF token.
To make everything more clear, your spring-mvc-config.xml should contain this:
<util:list id="csrfAllowedUrlPatternsList" value-type="java.lang.String" >
<value>/checkout/callback/secure3d</value>
</util:list>
I believe that this is valid for the csrf.allowed.url.patterns as well.
The regex should apply to the call back URL (i.e /checkout/callback/secure3d) instead of the initiator.

Is it bad practise to serve an error 403 page for an application-level policy?

Say I have a website that allows anyone to log in through oauth or similar, but only allows certain uses to create or modify content. Should they somehow make a request for page for creating a new post, I'll do a check and redirect them if they don't have the appropriate permissions.
It is considered acceptable to redirect to the "403 Error" page in this situation? There was no actual HTTP response with a 403 status code, there was no database- or server- level query that was failed - just my business logic. Am I misappropriating the idea of HTTP status codes if I serve an error 403 page with a specific explanatory message?
You are free to do so, but I think if you want to expose an API you would use an actual 403 response because they carry meaning that will be nicely handled by the client.
If you want to display a page to the client and will be using redirect, you will lose this meaning of the "403".
Isn't it better to just redirect them to an explanation page without including the "403" code. Or better yet, redirect them to a more helpful place, like the sign up page if that is what they have to do to make a post, or back to the original page with a floating message.
We want to help the user get closer to their goals instead of confusing them with technical error codes.
There is often a lot of discussion about this very topic and it comes down to the following choices:
a 5xx? Of course not. This is not a server error.
a 400? Not really, it wasn't a malformed request.
a 401? Probably not, 401 is generally for authorization in general, not application-level permissions. If your user has already logged in but has the wrong role, and you want to let the user know, then use something else.
a 404? Perhaps, as the server can't find the resource for this particular user, but if you want to tell the user "well such a resource is available but you can't have it because you lack permissions" then go with something else.
a 403? Actually, this one makes a lot of sense. Here is the definition from the RFC
403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. 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.
In your question you mention your intention to redirect the user. If you are making a RESTFUL web service then just return the 403. If you are doing an entire web app, you can control the 403 and redirect....

Get the final destination after WP_Http redirects (WordPress)

I'm doing some requests to an API via WordPress, and the API uses SSL connections if they're turned on in the API settings. I'd like to determine whether SSL is turned on or off without having to ask the user if SSL is turned on on their account, and the API does a good job at redirecting, meaning
If I access http://api/endpoint and SSL is turned on, I'm redirected to https://api/endpoint
If I access https://api/endpoint and SSL is turned off, I'm redirected to http://api/endpoint
Now what I'd like to do is see whether a redirect happened or not and record that to my options so that the other requests are fired to the correct URL without any redirections.
So my question is: is there a way to determine the final destination after firing a WP_Http->request() when the request is being redirected?
I can't see any info about that in the response arrays, I only get to see the final response but I have no idea what URL that came from. What I can do is set the redirection parameter to 0 and catch the max redirects allowed error, but that's not bullet-proof, since I still don't know whether the redirect happened from http to https or simply another page under http.
I hope this all makes sense, let me know if you have any ideas.
Thanks!
~ K
check $response['headers'] - they may contain 'location' key.
It all depends on the HTTP library you are using.
See class-http.php(wp 3.0.1) file:
line 1393, http_api_curl action - curl handle available directly to catch anything.
fopen:
check lines 887-888, and $http_response_header variable.
also, try to override processHeaders function as it has an access to raw http headers.
The WP_Http class processes the headers and removes all but the last one. So you could do what jetdog described above. Check the original URL and compare it to the returned $response['headers']['location']. If it is different, than you know it redirected.

Resources