I have created a site in Sharepoint services and hosted in IIS 6.0, the site is revealing few sensitive information like server name in the response. Please help me to secure or hide this information. The request and response is as given below (sensitive information is marked in bold lines).
Request –
GET /Finance/_layouts/userdisp.aspx HTTP/1.1
Host: (Server IP)
Accept: */*
Accept-Language: en
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Connection: close
Response –
HTTP/1.1 200 OK
Date: Wed, 29 Jun 2011 00:08:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6421
X-AspNet-Version: 2.0.50727
Set-Cookie: WSS_KeepSessionAuthenticated=443; path=/
Set-Cookie: MSOWebPartPage_AnonymousAccessCookie=443; expires=Wed, 29-Jun-2011 00:38:33 GMT; path=/
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 32318
You can hide the Server Name reported in the headers by using URLScan:
http://www.iis.net/download/urlscan
Related
Problem description
When making a HTTP POST request to my Express app (Node.js) the server responds with two "100 Continue" responses and after that a "200 OK" response, when there should only be one "100 Continue".
Postman manages to ignore the second "100 continue" and reports success but another app I'm building with Mule ESB doesn't accept the extra "100 continue" and fails.
The app otherwise handles the POST request without any problems, data is written to the database and so forth.
About the technical enviroment
The Express app is running on a SUSE-server. Nginx serves as a reverse proxy. I manage the multiple Express apps with PM2.
At first i was using a separate Express app, with a proxy package, to act as a reverse proxy. But i switched it out to using Nginx as the reverse proxy, thinking that might have been the issue. But that made no difference.
I have tried the exact same setup with the express reverse proxy on my local machine and that doesn't return "100 Continue" at all, only "200 OK".
I can't figure out why the exact same app returns different responses when it's running on local/server.
Example response
**REQUEST**
POST /<my-endpoint> HTTP/1.1
Host: api.<my-server>.se:443
User-Agent: AHC/1.0
Connection: keep-alive
Accept: */*
Content-Type: application/json; charset=UTF-8
Content-Length: 123
**RESPONSE**
HTTP/1.1 100 Continue
Strict-Transport-Security: max-age=94608000
Date: Thu, 09 May 2019 10:11:34 GMT
Set-Cookie: WASID_HAG=f88cc3f3525ed06b; path=/; domain=.<my-domain>.se
Set-Cookie: WAAK_HAG=41ef118d9c4608f158cfbdcb0140e652; path=/; domain=.<my-domain>.se; secure
Set-Cookie: UPD=6; path=/; domain=.<my-domain>.se
Set-Cookie: RGSC16972=1030; path=/; domain=.<my-domain>.se
HTTP/1.1 100 Continue
Strict-Transport-Security: max-age=94608000
Date: Thu, 09 May 2019 10:11:34 GMT
Set-Cookie: WASID_HAG=f88cc3f3525ed06b; path=/; domain=.<my-domain>.se
Set-Cookie: WAAK_HAG=41ef118d9c4608f158cfbdcb0140e652; path=/; domain=.<my-domain>.se; secure
Set-Cookie: UPD=6; path=/; domain=.<my-domain>.se
Set-Cookie: RGSC16972=1030; path=/; domain=.<my-domain>.se
HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Thu, 09 May 2019 10:11:34 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 227
Access-Control-Allow-Origin: *
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
ETag: W/"e3-aMSDU6iiOn52HqHZuJKLaZNt38k"
Set-Cookie: WASID_HAG=f88cc3f3525ed06b; path=/; domain=.<my-domain>.se
Set-Cookie: WAAK_HAG=41ef118d9c4608f158cfbdcb0140e652; path=/; domain=.<my-domain>.se; secure
Set-Cookie: UPD=6; path=/; domain=.<my-domain>.se
Set-Cookie: RGSC16972=1030; path=/; domain=.<my-domain>.se
Cache-control: no-store
What could be causing the multiple "100 Continue" responses and how can i prevent them?
Since the app doesn't return any "100 Continue" responses at all on my local machine could there be something with the server/firewall that's causing this?
We are currently loadtesting a Sharepoint environment hosted in IIS8.5 (On Windows 2012R2), using Loadrunner 11.52. We are using the WinINET based replay mechanism as there were SSL issues when trying to use the LR sockets implementation.
The authentication for the site is set to allow Windows Authentication. The users are all unique Active Directory users.
We have an issue where after starting 50 users, the users start failing due to them being unable to authenticate.
We have captured both successful (first 50 users) authentication and unsuccessful (users after the first 50) auth using Fiddler.
On initially loading the web page, the server returns a 401 with authentication headers as expected:
Request:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Response:
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
request-id: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 2
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
WinINET then handles this appropriately, returning a Kerberos auth token, which the server accepts:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate YIISMQYGKwYBBQUCoIISJTCCEiGgMDAuB...<long-auth-token-string>...=
Response:
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Wed, 11 Mar 2015 07:13:44 GMT
Last-Modified: Thu, 26 Mar 2015 07:13:44 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-AspNet-Version: 4.0.30319
SPRequestGuid: ad71f69c-db17-d049-46c6-15c51828a26e
request-id: ad71f69c-db17-d049-46c6-15c51828a26e
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 40
SPIisLatency: 0
WWW-Authenticate: Negotiate oYGzMIGwoAMKAQChCw...<long auth token>...=
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 80492
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" lang="en-US">
<head><meta name="GENERATOR" content="Microsoft SharePoint" /><
...
Some googling has suggested that the "YIIS" at the beginning of the auth token indicates that it has chosen Kerberos in response to the Negotiate auth option. This works fine for the first 50 users we start (each with unique AD user credentials).
However, for the 51st user, and each subsequent user, WinINET seems to start attempting to use NTLM authentication instead, which the server rejects.
Request (same as previously successful user):
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Response (same as previously successful user):
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-6b4f-d049-46c6-1e90257415f1
request-id: 6a71f69c-6b4f-d049-46c6-1e90257415f1
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
Client then sends the request for auth:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAA...<short NTLM auth token>...==
Some googling suggests that the T1R at the start of the auth token means it has chosen to use NTLM this time, instead of Kerberos which was used for all the users up till this one.
The server responds with another 401 to this:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAACAAIADgAAAAVgonicMgf76hzy7QAAAAAAAAAAL4AvgBAAA...<long NTLM auth token>=
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
request-id: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
Wininet then sends another auth request as follows:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAKIAAACEAYQBu...<much longer NTLM token>...=
Which results in another 401:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
request-id: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 236
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
At this point WinINET seems to give up, and passes the 401 on to LoadRunner which then fails the user.
The first 50 users keep working as normal. We can also load another user manually through IE while those 50 are still running. We can also wait some time and eventually we can start more users.
So, there seems to be two issues here:
Why is WinINET changing to use NTLM auth instead of Kerberos after 50 users have been started?
Why is the server rejecting the NTLM auth.
Any ideas on what might be causing this, and/or how I can investigate further, would be very appreciated. My suspicion is that it may be some sort of Active Directory limit that blocks Kerberos from working for a period after 50 users have been authenticated, however I do not know how to prove/disprove that.
Thanks.
I am essentially having the same issue as this person here:
IIS 8.5 MVC5 Client Cache is ignored
I assume its more an IIS 8.5 config issue rather than anything to do with Azure.
Any thoughts or suggestions??I also tried setting the cache in c# but that didnt work and also tried to add a custom header through the web.config of type 'cache control' but ended up with a mixed result of:
HTTP/1.1 200 OK
Cache-Control: no-cache,max-age=259200
Content-Type: text/javascript; charset=utf-8
Date: Wed, 18 Mar 2015 11:39:42 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/8.5
Set-Cookie: ai_session=24c1f2adcaf647e4b2c3a741d6474618|2015-03-18T11:02:37.3489398+00:00|2015-03-18T11:39:43.2134436+00:00; expires=Wed, 18-Mar-2015 12:09:43 GMT; path=/
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-UA-Compatible: IE=Edge
Content-Length: 4956
What is the best way to get IIS to set the headers for woff files so that they can be served from the client browser cache.
I'm working on an MVC .NET site that is hosted in IIS7.5, served through cloudflare with static caching turned on. The site uses a custom woff web font. When requests are made for pages that use these fonts IIS is serving them with the headers shown below. Subsequent requests all look the same. To me it looks like these are not getting cached by the client browser. I'd expect the server to be responding with 304 (Not Modified) and then the browser should serve the woff from its cache.
Request Headers
GET /blah/Content/fonts/AzoSans-Thin-webfont.woff HTTP/1.1
Host: blah.co.uk
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
Accept: */*
DNT: 1
Referer: http://blah.co.uk/bundles/Content/stylesheets/main?v=f9NXr53WMUdV9DfYJMkEU_5QZZi0g8eB1lB5lqxgdXc1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: __cfduid=d96b367152ae58725c15e5946cf1d67f41415385741070; ASP.NET_SessionId=3tcc3e1nd0z005tlknrbph5h; redesign#lang=en
Response Headers
HTTP/1.1 200 OK
Date: Fri, 07 Nov 2014 19:27:57 GMT
Content-Type: application/font-woff
Content-Length: 27728
Connection: keep-alive
Last-Modified: Thu, 06 Mar 2014 10:40:46 GMT
ETag: "0cbfc872839cf1:0"
X-Powered-By: ASP.NET
CF-Cache-Status: HIT
Vary: Accept-Encoding
Expires: Fri, 07 Nov 2014 23:27:57 GMT
Cache-Control: public, max-age=14400
Accept-Ranges: bytes
Server: cloudflare-nginx
CF-RAY: 185bee60092d0a90-LHR
The problem here seems to be that cloudflare is changing the headers. If I bypass cloudflare I get
Cache-Control:max-age=0
and the server responds with a 304 and the browser uses content from its cache.
I have website which is online. When I'am using it via browser everything is ok and this page is present in browser. When I'm using it as googlebot ( via webmastertools ) i'm getting error
HTTP/1.1 404 Not Found
Date: Mon, 19 Nov 2012 09:57:37 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: symfony=55240a0a341202d07fc96cbc1c1bcca5; path=/
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
and rest of the html code...
same thing when I'm trying to validate it via wc3 validator.
Please help :( I tryied everything :(
website address is mojaczestochowa.pl
If more info is needed please let me know.
Try to check the pae with web-sniffer and set user agent to google.bot
Here is the exact query, which will simulate server's response to the GoogleBot crawler:
https://websniffer.cc/?url=http://mojaczestochowa.pl/&uak=9