This one has me perplexed...
On my website, I am getting Mixed content errors in my console yet when inspecting the source, the urls it says are http are showing as https?
In fact, a search for anything with http:// returns nothing.
Inspection shows:
<img src="https://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default" data-lazy="https://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default" alt="2 Bedroom Apartment for Sale in Strand North" title="2 Bedroom Apartment for Sale in Strand North" class="lazy loading-F5F5F5">
Yet I get this error:
Mixed Content: The page at 'https://www.immoafrica.net/residential/for-sale/south-africa/?advanced-search=1&st=' was loaded over HTTPS, but requested an insecure image 'http://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default'. This content should also be served over HTTPS.
The page is requesting the following https URL:
https://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default
…but the server is redirecting that https URL to the following http URL:
http://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default
Paste that https URL into your browser address bar and you’ll see you end up at the http URL.
Or try it from the command line with something like curl:
$ curl -i 'https://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default'
HTTP/2 301
date: Sat, 06 Jan 2018 01:56:57 GMT
cache-control: max-age=3600
expires: Sat, 06 Jan 2018 02:56:57 GMT
location: http://images.immoafrica.net/aHR0cHM6Ly9yZXZvbHV0aW9uY3JtLXJldm9sdXRpb24tcHJvcGltYWdlcy5zMy5hbWF6b25hd3MuY29tLzU2LzE3MTk4OC8xMjcxOTk0X2xhcmdlLmpwZw==/fb5c609f3c1506a8798dfa620ccf8a15?1=1&width=420&height=310&mode=crop&scale=both&404=default
server: cloudflare
cf-ray: 3d8b1051cfbf84fc-HKG
…and notice th server sends back a 301 response and a location header with the http URL.
So the problem seems to be, that images.immoafrica.net site isn’t served over HTTPS/TLS and instead redirects all requests for https URLs to their http equivalents.
There’s nothing you can do on your end to fix that — other than creating or using some kind of HTTPS proxy through which you make the requests for images.immoafrica.net URLs.
Instead of using https:// use //. This will stop mixed content issues.
Related
I am working on a RESTful web application using Go + gorilla/mux v1.4 framework. Some basic security testing after a release revealed an Open URL Redirection vulnerability in the app that allows user to submit a specially crafted request with an external URL that causes server to response with a 301 redirect.
I tested this using Burp Suite and found that any request that redirects to an external URL in the app seems to be responding with a 301 Moved Permanently. I've been looking at all possible ways to intercept these requests before the 301 is sent but this behavior seems to be baked into the net/http server implementation.
Here is the raw request sent to the server (myapp.mycompany.com:8000):
GET http://evilwebsite.com HTTP/1.1
Accept: */*
Cache-Control: no-cache
Host: myapp.mycompany.com:8000
Content-Length: 0
And the response any time is:
HTTP/1.1 301 Moved Permanently
Location: http://evilwebsite.com/
Date: Fri, 13 Mar 2020 08:55:24 GMT
Content-Length: 0
Despite putting in checks for the request.URL to prevent this type of redirect in the http.handler, I haven't had any luck getting the request to reach the handler. It appears that the base http webserver is performing the redirect without allowing it to reach my custom handler code as defined in the PathPrefix("/").Handler code.
My goal is to ensure the application returns a 404-Not Found or 400-Bad Request for such requests. Has anybody else faced this scenario with gorilla/mux. I tried the same with a Jetty web app and found it returned a perfectly valid 404. I've been at this for a couple of days now and could really use some ideas.
This is not the claimed Open URL redirect security issue. This request is invalid in that the path contains an absolute URL with a different domain than the Host header. No sane client (i.e. browser) can be lured into issuing such an invalid request in the first place and thus there is no actual attack vector.
Sure, a custom client could be created to submit such a request. But a custom client could also be made to interpret the servers response in a non-standard way or visit a malicious URL directly without even contacting your server. This means in this case the client itself would be the problem and not the servers response.
I am trying to capture packets on Wireshark for a website. But, since safari opens only the https format, Wireshark is not capturing it - it may be seen in TLS but I want to see the http format. How to do this?
Many websites, including nytimes.com, redirect from HTTP to HTTPS. You can see this with the Terminal command curl, using its -i (show header info) option:
$ curl -i http://nytimes.com
HTTP/1.1 301 Moved Permanently
Server: Varnish
Retry-After: 0
Content-Length: 0
Location: https://www.nytimes.com/
Accept-Ranges: bytes
Date: Wed, 01 Jan 2020 20:27:39 GMT
X-Served-By: cache-pao17428-PAO
X-Cache: HIT
X-Cache-Hits: 0
X-Frame-Options: DENY
Connection: close
X-API-Version: F-0
The 301 status and Location: header tell the client, essentially, "this isn't the URL you want; go load 'https://www.nytimes.com/' instead". Safari (and other browsers) follow this redirect automatically. If you load "http://nytimes.com" in Safari, you'll see that it's both switched to HTTPS and added "www." to the domain name, because that's what the redirect told it to do.
Also, note that the Content-Length: header is 0, and there's nothing but a blank line (that you can't see above) after the header that curl printed. That means there's no actual content at the http:// URL. The server doesn't even bother to serve the page content over HTTP, only over HTTPS.
Some servers/domains go even further to require their clients to use HTTPS. Some are configured to serve an HTTP Strict Transport Security (HSTS) header, which tells the browser to never load anything from that domain over HTTP, but always auto-switch to HTTPS instead. They can also register for HSTS preload, which tells browser developers to include an HSTS policy for the domain without needing to hit the server to get it. nytimes.com doesn't do this, but you can use this site to check other domains. Here's a check on google.com:
$ curl https://hstspreload.com/api/v1/status/google.com
{"domain":"google.com","chrome":{"present":true,"include_subdomains":true,"last_updated":1577844002},"firefox":null,"tor":null}
...which says it's included in Chrome's preload list, but not Firefox's or Tor's. AIUI Safari uses Chrome's list, so google.com should always be auto-switched to HTTPS in Safari.
Your issue is not related to the browser. Many websites will automatically redirect http traffic to https to insure a secure connection.
If you apply the following display filter
http.response.code == 301
You will notice that the webserver is redirecting to the secure https endpoint.
Wireshark capture for http://nytimes.com
If you want to experiment with a website that will not auto-redirect you to https, I suggest using
http://example.com
Follow these steps:
Go to Safari > Preferences.
Click the Advanced tab.
Check the "Show full website address" box.
Close the Preferences window.
And now you can see the full URL in Safari.
I need help in figuring out how to enable CORS (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) on an object-storage bucket please?
At the moment, Cross-Origin-Resource sharing is enabled for OCI ObjectStorage native & Swift API.
➜ ~ git:(master) ✗ curl -I https://objectstorage.us-phoenix-1.oraclecloud.com
HTTP/1.1 404 Not Found
Date: Wed, 12 Dec 2018 01:52:00 GMT
Connection: keep-alive
opc-request-id: 286901e2-4180-812c-2779-18b415009904
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST,PUT,GET,HEAD,DELETE,OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Access-Control-Allow-Credentials,Access-Control-Allow-Methods,Access-Control-Allow-Origin,Connection,opc-client-info,opc-request-id
Sadly, it seems like Oracle's object storage does not support CORS headers (nor ACLS - shame).
If you are generating pre-signed URLs to files in the private bucket, you could use the "Sec-Fetch-Mode" request header to know if the browser will check CORS for file.
See details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode
So you can do the following:
if Sec-Fetch-Mode = cors, you should download the file to your server and then send it to the browser (that way the file origin will be the same as your application).
if it's not, then you can generate a pre-signed URL and redirect the browser to it.
One last thing, IE and Safari browsers will not send the "Sec-Fetch-Mode" header even if they still check for cors, so in their case, the solution of sending the file through your server is to be done.
More about pre-signed URLs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
I am using ESP8266-Websocket, aws-sdk-arduino(cleaned branch) and pubsubclient to try to comunicate with aws iot mqtt service using websockets.
My question is about the first connection request. I am using this browser app as reference https://github.com/awslabs/aws-iot-examples and the sign code from aws-sdk-arduino (that works fine calling the aws iot restful api)
My request was this (after connect to the endpoint at 443 port):
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
host: ENDPOINT.iot.us-west-2.amazonaws.com
Connection: Upgrade
Upgrade: websocket
Origin: file://
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: D2alJOyUkBlR+8yhv2UBLg==
Sec-WebSocket-Protocol: mqtt
but I keep getting
HTTP/1.1 403 Forbidden
content-type: application/json
content-length: 241
date: Fri, 18 Mar 2016 18:34:57 GMT
x-amzn-RequestId: f2edfe83-1bbc-4481-97e0-39ccfc4d1c2f
connection: Keep-Alive
x-amzn-ErrorType: ForbiddenException:
am i missing some request header parameter? is there anyway to get a better feedback from x-amzn-ErrorType: ForbiddenException? am i messing up in the sign process? (even though it works for rest call)
Yeah, I've finally got response status 101 switching protocols \o/
when you are building the request, it must be:
GET /mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
instead of
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
the js example that I was following was using the full path. When I got the request built by chrome (throught developer tools) the path was full as well. Just after use firebug I got the real request that browser was sending to the server (with short path).
now I can continue to try the solution (mqtt over websockets at esp8266) :-) if it works, I will share the code ;-)
My server returns the following headers for a file:
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:155
Content-Type:text/css
Date:Thu, 06 Feb 2014 18:32:44 GMT
ETag:"99000000061b06-9b-4f1c118fdd2f1"
Keep-Alive:timeout=5, max=100
Last-Modified:Thu, 06 Feb 2014 18:32:37 GMT
As you can see, it doesn't return cache-control header, however it returns ETag and Last-Modified headers.
My question is whether browser is going to cache the requested file? I can observr that during the following requests the browser sends ETag:"99000000061b06-9b-4f1c118fdd2f1" in headers and server returns status code 304.
And second question: Will browser cache resource and request it with ETag if Cache-control is set to no-cache?
For first part of question - It is up to your browser (its implementation and configuration) if the response will be cached and when will be revalidated. The only (standardized) difference between browser behaviour with validation headers and behaviour without validation headers is that former one can reduce traffic with server using validation.
Second question: Yes. Browser will cache resource but every time you open the page browser will ask origin server if resource was not modified. If not modified server will respond 304 and browser will display cached content. Otherwise server will send new content.
My guess would be ETag can serve as cache-control: no-cache.