i have a coldfusion 2016 website running over IIS 7.0 . I want to ensure it is not susceptible to HTTP smuggling
i want to enable HTTP 2 to resolve this issue ..
Question : what all places i have to make changes to enable HTTP 2 ?
IIS
is there any setting in coldfusion 2016 process as well to enable HTTP 2?
below is some reference material on what HTTP smuggling is :
http://projects.webappsec.org/w/page/13246928/HTTP%20Request%20Smuggling
https://www.youtube.com/watch?v=PFllH0QccCs
Thanks
Related
I am using Postal PIN Code API for getting Post Office(s) details search by Postal PIN Code in angular 5 application. Below is the url of the external API :
http://postalpincode.in/api/pincode/{**PINCODE}**
I am issuing a GET request from the application but it is giving me below error :
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access
Although this request is working perfectly fine from browser and postman. I understand that we need to configure our server with cross-domain policies for accepting cross-domain request but this is an external API and I don't have control over it. How can I resolve this issue?
Thanks in Advance !!
Best: CORS header (requires server changes) CORS (Cross-Origin Resource Sharing) is a way for the server to say “I will accept your request, even though you came from a different origin.” This requires cooperation from the server – so if you can’t modify the server (e.g. if you’re using an external API), this approach won’t work.
Modify the server to add the header Access-Control-Allow-Origin: * to enable cross-origin requests from anywhere (or specify a domain instead of *). This should solve your problem.
2nd choice: Proxy Server If you can’t modify the server, you can run your own proxy. And this proxy can return the Access-Control-Allow-Origin header if it’s not at the Same Origin as your page.
Instead of sending API requests to some remote server, you’ll make requests to your proxy, which will forward them to the remote server.
Here are a few proxy options.
Ref: https://daveceddia.com/access-control-allow-origin-cors-errors-in-angular/
I have set up SSO using weblogic on windows and Kerberos, It is working fine for the http pages, however I observed a strange behavior on https pages which requires CONFIDENTIAL setting for the transport, It works fine if I first access a page on http which is not configured as secured in web.xml(Transport-Gurantee as None) and then the https page.
But If I try to hit the https url directly which is configured with Transport-Gurantee as CONFIDENTIAL then it shows the Basic Auth Dialog and a 401 Unauthorized response, Looking at the logs I see that the Server responded with the WWW-Authenticate but browser showed the Basic Auth Dialog in response instead of getting the Authorize token.
Does anyone has any idea on what might be issue here, If there is any problem with the browser settings then it would not have worked irrespective of accessing the http url first.
I can see the following error log in weblogic console
Malformed request "Can not parse URI from http request". Request parsing failed, Code: -1
Found one of the link here
SPNEGO on IBM WebSphere Portal 6.1 with https
For my case it is weblogic 12c , I don't think reinstalling 12c is a valid solution for it
Ok I got it fixed , It turns out to be an issue with the browser configuration , the https://myserver.domain.com was not inside the intranet domain and the control to do that rests with the windows Admin team, once they added it , the https urls are also working fine.
This question already has answers here:
MVC web api: No 'Access-Control-Allow-Origin' header is present on the requested resource
(17 answers)
Closed 4 years ago.
From one side I have an ASP.net web application that contains a web api module.
On the same machine I have an angular 2 client application which is consuming the web api controllers crud methods. The angular 2 uses a basic http service with the uri of the localhost with the port number on which the web api runs on. I run the web api application and when the angular 2 tries to consume a Get request, I get this error message (22770 is the port of the web-api, 4200 is the port of the angular 2 application):
Failed to load http://localhost:22770/api/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access.
Although this is quite a common question, mine is a little bit different:
CORS is defined as:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses
additional HTTP headers to let a user agent gain permission to access
selected resources from a server on a different origin (domain) than
the site currently in use
BUT - I'm working with the same domain - on my local machine (localhost).
What is the problem and how can I solve it ?
OK - Investigated it a little bit and reached the reason for that error message when working on the same local host - It appears that a different port is considered as a different domain.
Exceptional addition I noticed:
"Internet Explorer does not consider the port when comparing origins"
You need to enable CORS (cross origin request) in your web api. Follow instruction given in below page
https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api
I am trying to test an ASP.NET Web Api locally using IIS Express. When I use Chrome and hit the url (localhost:5000/api/test, for example) the json displays fine, but when using Postman I keep getting unauthorized 401.2 when hitting the same url. The api controller has Anonymous access on the route.
On the error message, one of the likely causes is:
Integrated authentication is enabled and the request was sent through a proxy that changed the authentication headers before they reach the Web server.
Is Postman somehow changing the headers?
[2019 Update]
Got the same issue, I couldn't debug an ASP Core 2.1 API using Postman when running on the local machine using IIS Express. I kept on having "Could not get any response" despite it was working fine on a browser.
Following troubleshooting steps explained here PostmanLabs Github, I noticed into Postman console that this was coming from a certificate issue.
Disabling SSL Verification from Postman Settings > General allowed the request to pass through.
Looks like it's your proxy.
I haven't found the proxy setting in postman. So I deleted postman for Win and installed postman for Chrome. Possibly Postman gets the environment from Chrome.
Anyway the resolution is to use Postman for Chrome instead of Postman for Win.
I have a localhost WebAPI site up with IIS Express (HTTPS). Postman started to respond as expected to GETs and POSTs after I changed (in Postman)
File --> Settings --> Proxy
to: "Use the system proxy"
and turning on: "Respect HTTP_PROXY ...".
I had earlier set up a custom proxy that wasn't working with HTTPS.
I am trying to get an MVC3 application working on a Windows Server 2008 R2 box. The server is running IIS 7.5. The application is setup with anonymous authentication and a v4.0 framework application pool. I have given IUSR and IIS_IUSRS access to the directory until I switch to using a service account.
I have tried the following:
Registered ASP.NET 4 with IIS (%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -ir)
I have installed MVC3 on the server from http://www.asp.net/mvc/mvc3.
I am still receiving an HTTP 403.14 response: "HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory."
If I throw in a dummy index.html file, the page gets served. It seems to me like a module isn't intercepting the request to point the request to the home controller.
Answer: While MartinHN's answer did resolve the issue, it would result in a performance hit when serving static files. Thanks to his answer I started doing some searching and found that there is a IIS7 hotfix available which will allow ASP.NET 4 applications to handle extensionless URLs without running all modules for each request. The hotfix is available here: http://support.microsoft.com/kb/980368. After installing this hotfix my application was serving content as expected, without the Web.config change.
Might be one of the following...
Check your web.config for the line:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
...
</system.webServer>
And make sure that the application pool is set to the Integrated Pipiline.
You can also try to reset the Handler Mappings in IIS. Click the site --> Handler Mappings --> Revert to parent (link should be on the right sidebar).