For an IoT deployment, I am looking to redirect requests to my custom domain to a different URL based on the source IP, i.e. I will have a small number of allowed clients with known public IPs hitting a URL - https://www.example.com, and each one needs redirecting to a unique URL. The target URL is not neccesarily a domain landing page, so I can't use anything DNS-based.
I would ideally want to use some kind of online API/service. It will be frequently reconfigured by a non-programmer user, so it needs to be as easy to configure as possible.
I've checked out URL redirecting services, load balancing services, and CDNs but I can't seem to find something that will redirect based on inspecting the source IP.
Related
If I set up a simple web server online (eg nginx), and generate a very large random string (such that it is unguessable), and host that endpoint on my domain, eg
example.com/<very-large-random-string>
would I be safe in say, hosting a webapp at that endpoint with no authentication to store my personal information (like a scratch-pad or notes kind of thing)?
I know google docs does this, is there anything special one has to do (again, eg for nginx) to prevent someone from getting a list of all available pages?
I guess I'm asking is there any way for a malicious actor to find out about the existence of such a page, preferably irrespective of what web-server I used.
I'd be pretty alarmed if my online bank started using this system, but it should give you a basic level of security. Bear in mind that this is security through obscurity, which is rather frowned upon and will immediately turn into no security whatsoever the moment someone discovers the hidden URL.
To prevent this from happening, you will need to take a few precautions:
Install an SSL certificate on your server, and always access the url via https, never via http (otherwise the URL path will be sent in plain view and visible to everyone along the way).
Make sure your secure document contains no outgoing links. This includes not only hyperlinks (<a href="...">) but also embedded images, stylesheets, scripts, media files and so on. Otherwise the URL will be leaked to other domains via the Referer request headers.*1
(A bit of a no-brainer, but) make sure there are also no inbound links to this page. Although they aren't so common now, web hosts used to generate automatic "web stats" pages showing the traffic to each web domain. Some content management systems generate a site map automatically. This would be just as bad.
Disable directory browsing on your server. In other words, make sure that someone who visits the directory level above your hidden directory isn't presented with a list of subdirectories.
Bear in mind that the URL will always be visible in your address bar and browser history, and possibly in other places like your browser's cookie jar. Your browser will probably provide the rest of the URL by auto-complete when someone types the domain into your address bar.
*1: Actually, your browser will only send a Referer header when you access other https pages, but still...
We have multiple websites under Azure DNS Zone
ourbusiness.net
Given multiple Web Apps like So:
foo.ourbusiness.net
bar.ourbusiness.net
We would like to add URL redirects(Correct term?) such that navigation to the following:
foos.ourbusiness.net
thafoo.ourbusiness.net
morefoo.ourbusiness.net
all redirect to:
foo.ourbusiness.net
Would need the same for other apps like bar, baz etc, not just foo.ourbusiness.net.
We do not want an alias, the browser navigation needs to navigate to foo.ourbusiness.net in the browser URL.
I think it is possible using a combination of multiple A Records and a Ptr record. This would require a static IP or Virtual IP address(however that works.)
We use SSL.
What is the most direct way to accomplish above requirement in Azure? Thx..
According to your request, I think the most direct way is to set multiple A records.
It does need a IP address for the Web App and this solution need some cost. However,
NOTE: The IP address may change if you delete and recreate your web app, or change the web app mode back to free.
You can find more details about how to get an IP for Web app and in this document: Map an existing custom DNS name to Azure Web Apps
So,if you worry about this, I recommend you to configure CNAMEs .
Based on this requirement "We do not want an alias, the browser navigation needs to navigate to foo.ourbusiness.net in the browser URL." you need a HTTP redirect to tell the browser to navigate to a different address, i.e. foo.ourbusiness.net. That's not provided by Azure DNS but you could look at something like Azure Functions to create a HTTP reply with the correct HTTP return code etc.
We are setting up a website with secure and non secure pages. These have been added for mapping in uriworker.properties. The domain name in the urls are different . Example nonsecure url is x-y-z.a.b.org and our secure url is x-y-secure-z.a.b.org.Both of these domains are part of our DNS entry. We do not have any redirect rules configured within the webserver. But when we try to access the secure url https://x-y-secure-z.a.b.org, webserver is sending the request as http://x-y-secure-z.a.b.org:443. Due to the scheme not being https , the application does not identify this as secure request and is returning a 302 to the https url. This redirection happens infinitely and then an error appears which says that page is not redirecting properly.
After a lot of analysis , we figured out that the application had a hardcoded check on the scheme of the domain name to be in a certain format as secure.xyz.
I am a new to web deployment and I am deployed a website for testing on IIS, the website is non secure (http) site but one page should be secure (https).
Can anyone suggest me how I can achieve it and it should not warn the user while switching between 'http' and 'https'.
SSL or Secure Socket Layer would be bound to a website through bindings. That is, you can tell IIS to redirect the incoming request traffics to a website, when for example the requested URL would be like http://domain.com/ or https://doamin.com, or http://200.202.150.200:8080/ or stuff like that.
Therefore, it's not a matter of IIS to set HTTPS only for one page. It's rather how to manage your URLs while redirecting user. In other words, it's a navigational matter.
I havent used IIS but I did this recently with Apache.
I did the following:
Set up a redirect for the page that you wish to secure so it redirects to HTTPS.
Set up a redirect for every other page to redirect from HTTPS to HTTP
Ensured static files such as images css and js are not affected by the above rules (These files need to work on both HTTP and HTTPS
If you need this commercially, I would recommend to use Helicon tool to redirect that particular page to HTTPS.
Using Helicon tool you can redirect the HTTP request to HTTPS for any specific page or whole site by writing the Rules.
In IIS 7 there is way to define new rules in "URL Rewrite" section for a particular web site. By this you can define a regular expiration and based on that you can redirect any pages which matches the expression to the page which you want. Lets say you are going to redirect http:\x.com\sample.aspx to https:\x.com\sample.aspx. For this do the following steps:
select your website on IIS
click URL Rewrite
Add Rule(s)
Select Blank rule
Then define your pattern in this case : lets say ^sample(any page start with sample). you can define any expression as you like.
in Action section select Redirect in Action type dropdown
in Redirect URL put https:\x.com\sample.aspx
save it and restart your website
you can then add any other rules as you want o match your request
And also in some other complex scenarios you can write your own scripts here
I was recently looking around at some of the features my current web host offers, and am now wondering about a few things. Even if you can only answer part of this, I appreciate any help you can provide.
I have a domain, mydomian.com, and the host offers shared SSL so I can use HTTPS by using this address https://mydomain.myhost.com. The SSL certificate is good for *.myhost.com.
I don't know a lot about SSL, but I'm assuming this means that the data between site users and ANY domain on myhost.com is encrypted. So was curious if this meant that if someone else on the same host as me somehow intercepted the data from my site would they be able to view it, since they would also have a https://theirdomain.myhost.com address, which uses the same SSL certificate? I may have no idea at all, and this was pretty much a guess.
If HTTPS is used on a login page, but after logging in the other pages are viewed over HTTP, is this a security issue?
Is there any way to show a web form via HTTP for bots like Google, but have real users redirected to the HTTPS version? Would be ideal if this could be done via .htaccess. I currently have some rewrite rules that redirect certain pages to HTTPS, but the rest as HTTP. So if a visitor visits the contact form they get the HTTPS version automatically, but it automatically switches back to HTTP for pages that don't contain forms. So, via htaccess, is there a way to direct real users to the HTTPS version, but have bots directed to the HTTP version? I would like these pages to still be indexed by the search engines, but would like users to see it via HTTPS.
Thanks in advance for any help you can provide.
I'm going to guess you'll be okay for number one. If your host does it correctly, individual subdomains never get to see the SSL keys. Here's how it would work:
Some guy with a browser sends an encrypted request to your subdomain server.
Your host's master server receives the request and decrypts it.
The master server sends the decrypted request to your subdomain server.
And any HTTPS responses you send back go through that process in reverse. It should be easy to check if they've set things up that way: If you can set up shared SSL without personally handling any key files, you're good. If you actually get your hands on some key files... not good.
For two: If you encrypt the login, you protect the passwords, which is good. But if you switch back to HTTP afterwards, you open yourself up to other attacks. See: Firesheep. There may be others.
And for three. Yes - definitely doable. Check out mod_rewrite. Can't give you an example, as I've never used this particular case, but I can point you to this page - particularly the section entitled "Browser Dependent Content."
Hope that helps!
Every traffic is encrypted, when you use https:// as protocol. (Except for some uncommon circumstances I won't talk about here). An SSL certificate's purpose is to prove the identity of the server, by combining it's public key with an identity. This certificate is only usable with the private key that belongs to the public one. In your case it seems that this certificate as well as the key-pair is provided by your hosting provider. I guess that neither you nor the other customers on the host have access to this private key. That means that only your provider is able to decrypt the traffic. Since that's always the case (he's running the server, so has access to every data), that should be no problem.
In most cases it is a security issue. On every further unencrypted http-request the client has to provide some information of the session to the server. These can be intercepted and used by an attacker. (simply speaking)
The bots should support https, why not redirect them? Anyhow: The important part is not to provide the page containing the form via https. To protect your user's data you should take care that the response is transferred via https.