Posts to my Azure Web App are being replied to with additional Http Header information, specifically the following:
Access-Control-Expose-Headers: Request-Context
Set-Cookie: ARRAffinity=xxx;Path=/;HttpOnly;Domain=ws.caxxx
Request-Context: appId=cid-v1:xxx
This appears to be due to Custom Domains configured on my site, i.e., the Azure site url is xxx.azurewebsites.net and I have a Custom Domain set ws.xxx.com. I say that because when I'm posting to the Azure url I do not see the Access-Control-Expose-Headers and the Request-Context lines in the headers.
I do not have CORS configured for this site, so I don't know why I am getting the Access-Control-Expose-Headers.
Note that this is the Production site. I have another Testing site where I do not have this problem! So there must be something with my Azure configuration.
On my Testing site, I can remove the ARRAffinity cookie by adding the httpProtocol clause to the web.config. However, when added to the Production site it throws a 500 error.
The posting devices are IoT devices, so I need to reduce the headers sent back to the devices.
Any advice is greatly appreciated!
Related
We have our Apache Websites secured using the password security which works well. Ive noticed If I add the following header to my browser requests I can bypass the security Authorization: Basicxxxxxxxxx. However, many other websites I visit use this same headers which requires me to always disble this header before visiting other sites.
Is there a way to configure Apache to recognize an additional headers to bypass security, so I can store this header in my browser settings and be able to visit other sites without having to disable it.
I need to understand how exactly works the bot-detection works on axs.com as I'm accessing many times this website and after a short while the login does not work any more and website is basically blocked.
By analyzing the network request and console I can see the following after clicking the login button:
Access to XMLHttpRequest at 'https://api.axs.com/proxy/v3/flash/migrate/authenticate?access_token=4f2be33d835e7197e245c54ff00e5fb4®ion=1&locale=en-US' from origin 'https://www.axs.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
WHAT I HAVE TRIED SO FAR:
Using multiple VPNs to change IP address (Failed)
Using an EC2 instance (failed)
Using Extension called "Trace" to completely delete all my trackable data and delete cookies (Failed)
Incognito window (Failed)
Proxy Server Paid and Free (Failed)
What else can I try?
I finally found the solution, it was needed only a better quality proxy. My steps:
At the beginning we used rotating proxy with brightdata from many different countries, but no luck with it.
Then we tried different proxy providers but always rotating, residential and mobile were tested. Again no luck.
We purchased US proxy from https://www.proxyrack.com/ and finally it worked. I guess the proxy quality is of vital importance. AXS security must have a pretty long blacklist for IP addresses.
I have a website hosted in Apache. its a spring framework application uses angular for front end.
This is being accessed through akamai technology. I have updated the application hosted in the origin server.
When I tried to access from browser it gives a blank page. After doing an 'CTRL + F5' its gives me proper website.
I am not able to sort this out why such behavior in the application. Can any expert in this help me out.
Thanks In advance
Bala
Your page might be cached in your browser. I'd recommend that you could check "cache-control" HTTP response header, e.g.
cache-control: max-age=0, no-cache
It can be controlled by either Akamai or Apache.
Lets say I have my website named SiteA.com running on an Apache web server. I have defined the ff. below on my httpd.conf file:
Header set Access-Control-Allow-Origin "CustomBank.com"
Questions:
Does this mean only CustomBank.com can access my site (SiteA.com) directly? or does it mean only my site (SiteA.com) can access the CustomBank.com domain directly? I am confused if this setting is for inbound or outbound.
In reality I don't have any CORS requirement needed for my site, so I didn't implement the setting mentioned above, the one below shows up in my response header.
Access-Control-Allow-Origin: *
Penetration Testing team said this setting is overly permissive. Do I just need to remove it? if not what should I do?
It means javascript loaded from CustomBank.com can make requests to your site (the site whose configuration has changed) via XMLHTPRequest in the background.
Since XMLHTTPRequest will send a users existing session cookie with your site, malicious scripts could do all kinds of nefarious/misleading things on behalf of your user. That's why * is not normally a suitable fix.
The restrictions apply to other script-like invocations that are more esoteric that you can read about in the specs.
Can anyone provide any insight into how CORS works on Rackspace Cloud Files?
I tried setting the value of "Access-Control-Allow-Origin" to the url of my webserver but I can still access the public url of the object by just pasting it into a browser.
Maybe I misunderstand how CORS works? Setting the access control allow origin to my web server would only allow the file to be accessed from the web server. Me, as a user pasting the url into the web browser, would be from a different origin, no ?
The documentation at Rackspace isn't the best sometimes for stuff like this (or I'm looking in the wrong place...)
That's not really what CORS is for. Cross-origin resource sharing (CORS) is a mechanism that allows Javascript on a web page to make XMLHttpRequests to another domain, not the domain the Javascript originated from, see CORS.
It has nothing to do with making an object or container public/private.
On Rackspace, CORS works according to this doc.