just wondering if there could be any issue building a shopping cart using Backbone.js and more specifically if there were any security issues using hash-bangs over HTTPS?
Also I guess I can POST credit card details through AJAX, correct?
Cheers,
You still need robots.txt to keep your urls from being indexed, even if you're using HTTPS. The #! (hashbang) as opposed to # (hash) provides a way to index sites by their url fragment. Instructions for disallowing are on the google page about indexing hashbang. In practice you likely won't have to worry about it because google's crawlers aren't authenticated and won't index an error. But if a Google Toolbar is installed the URLs with fragments may be sent to Google before Google determines that the URL+fragment will not be indexed. To simplify things, you could use # instead of #! after logging in; a # deep link will not be indexed.
If a request is made through HTTPS, it's encrypted, whether it's AJAX or not. If your backbone model url starts with https://, it will either send it encrypted or fail. From a network eavesdropping perspective, it's the same as posting without AJAX.
Related
Recently, I created my first website and registered at Google search console.
The address is https://www.chemjix.com. However, as I always landed on the insecure http address when entering just www.chemjix.com in the address bar, I use the index.html to forward to https and directly to the correct language (English or German). After adding the website to Google search console, I got the message for the http that it is not indexed because of "Soft 404 Website" and "Page with redirect".
Is that a problem and does Google therefore rank my website lower or something like that? And what would be the alternative, do I need to get rid of that redirection?
Thanks a lot
celdri
You should use your hosting provider's tools to setup your domain correctly. You should use only https, as these days this is a must have for websites.
Most providers have some kind SSL or integrated the free Let's Encrypt solution for a real free for life SSL.
If you have a working site in https, you may use the hosting provider's own solution (like in Cloudways for example we have a swith) to redirect every URL to https, or you should use .htaccess redirect rules.
You also can additionally take advantage of Cloudflare not just to domain managament and caching, but to setup, and handle and check full SSL route from user to server.
I've made a web app that stores persistent user data in localStorage. I've enabled HTTPS on my site, and I'd really like to flip the switch on HSTS. However, as far as I can tell, localStorage considers http://example.com and https://example.com to be different, so if existing users are redirected to the HTTPS version of my site, they can no longer access their data (though it still exists).
Long term, I want to build a new version of this app that offers more options for data storage. But in the short term, all I can think of is having a transition period where users at the http version are asked to migrate their data via some other (unknown) mechanism that both versions can access.
Is this a fair assessment of my options? Is there a way for https://example.com to access the localStorage of http://example.com? If not, is there anywhere I can put user data such that both versions can access it but other sites can't? Or should I ask them to download their data and re-upload it? That doesn't see ideal from a UX or (user) security standpoint.
Note that this web app doesn't interact with a server at all; everything happens with localStorage and the client.
Unfortunately there does not seem to be any way to directly retrieve localStorage contents for the less secure http copy of the site from the https site. reference
The workaround I have seen is to use an iframe loading a special page on the insecure site similar to this answer. The general theory is to have code in the iframe that sends messages using postMessage with localStorage data back to the secure page.
Unfortunately this approach does not allow you to disable http entirely, because otherwise your iframed http copy would not load.
I'm writing a Chrome packaged app for diagnosing web services. I want to be able to send a GET request to a URL and look at the headers and data in the response.
My problem is if a users visits a site that has the HSTS header set before using my app, my app will then be unable send GET requests to the http:// URLs for that domain because Chrome will automatically convert the http:// URLs to https:// ones before the request is sent out.
Is there anything at all I can do to prevent this? I've looked into the webrequest API and webview tag but I'm finding nothing that lets me ignore HSTS.
Is it possible to use https://developer.chrome.com/apps/sockets_tcp for this (I would need to be able to support http, https and gzipped data)?
Is there anything at all I can do to prevent this?
Probably not. If you already tested <webview> and it shares the HSTS list with the browser, then the network layer will transparently rewrite this for you.
Is it possible to use chrome.sockets.tcp for this?
Technically, yes, HSTS shouldn't matter for that. Practically, you would need to implement something like wget+SSL+gzip from ground up (in JS, NaCl or a Native Host - but in the latter case you don't really need built-in sockets).
I have a site on which users are supposed to jump back and forth between protocols (http vs https). For example, they may land on https://example.com/index.html, and then click through to http://example.com/test.html.
In order to accurately gauge the user behavior flow on google analytics, I need to treat both of these protocols as one single property in my GA setup.
google, however, makes you select a single protocol when defining a new web property. What is the best way to handle this? Let's assume https is my default - how can I trigger a pageview from the http site and have it be counted towards the https site's analytics?
I know there is a forceSSL option, but there is not much documentation around that:
By default, Google Analytics will match the protocol of the host page
when sending outbound requests. To force Google Analytics to always
send data using SSL, even from insecure pages (HTTP), set the forceSSL
field to true
Will this accomplish what I'm looking to do? Sending the data via SSL does not necessarily correlate to them recording the data as an SSL event.
My understanding of this issue is the following:
As far as Google is concerned, your HTTP and HTTPS properties ARE two separate entities.
The only way to lump them together is to force the entire site to use SSL, thus removing the HTTP property.
If this is an option, it will have the added benefit of increasing your search ranking.
I have an API (1) on which I have build an web application with its own AJAX API (2). The reason for this is not to expose the source API.
However, the web application uses AJAX (through JQuery) go get new data from its AJAX API, the data retrieved is currently in XML.
Lately I have secured the main API (1) with an authorization algorithm. However, I would like to secure the web application as well so it cannot be parsed. Currently it is being parsed to get the hash used to call the AJAX API, which returns XML.
My question: How can I improve the security and decrease the possibility of others able to parse my web application.
The only ideas I have are: stop sending XML, but send HTML instead. Use flash (yet, this is not an option).
I understand that since the site is public, and no login can be implemented, it can be hard to refuse access to bots (non legitimate users). Also, Flash is not an option... it never is ;)
edit
The Web Application I am referring to: https://bikemap.appified.net/
This is somewhat of an odd request; you wish to lock down a system that your own web application depends on to work. This is almost always a recipe for disaster.
Web applications should always expect to be sidelined, so the real security must come from the server; tarpitting, session tokens, throttling, etc.
If that's already in place, I don't see any reason why should jump through hoops in your own web application to give robots a tougher time ... unless you really want to separate humans from robots ;-)
One way to reduce the refactoring pain on your side is to wrap the $.ajax function in a piece of code that could sign the outgoing requests (or somehow add fields to it) ... then minify / obscurify that code and hope it won't get decoded so fast.