I am trying to embed 3D secure and net banking pages in an IFrame, and I am able to achieve it successfully for a few sites which I have tested. But I suspect if ALL the bank pages will open in IFrame.
What if any bank has set x-frame-otpions to SAMEORIGIN or DENY?
Tried searching for a tech spec regarding this, but couldn't find anything.
Is there a common thumb rule or convention (in any spec) that an authenticating bank should/shouldn't use this header? How do I believe if this will work for all the banks?
Any clarifications would be of great help.
P.S.: I know there are other ways of opening the authorization gateways. But still, I need clarity on this approach.
You typically wouldn't just open an iframe with the bank domain. Instead you open an iframe from an outside payments' provider domain(adyen, braintree etc.) and they, in turn, open another iframe inside so that they only have to allow payments' providers iframe to communicate with it.
What's interesting that those iframes still usually have same-origin policies.
Related
Looking for some strategy here. We have a secure (subscription-based) website that points to another website for streaming video. Currently, a savvy user could potentially share the link to the streaming page thus bypassing the login. Looking for ideas on how to:
Prevent sharing the link
Cloak the link...or
Make the link from the origin page point to a dynamically-generated URL that can only be visited once.
Thanks in advance!
Unless there is a form of streaming the video from the third party to your application (by streaming I actually mean sending the video in chunks of data to your backend, assembling them back together, and serving the actual assembled video as if it was hosted directly on the same host as the web application, I have personally done this using Amazon S3 for my open-source subscription-based CMS called phpReel) I don't think you can securely do this.
If you do want to go down this route please note that it might get expensive if you have a lot of active subscriptions but if you are interested you could check out these files as they showcase how I have done it for phpReel. I am afraid though that you might need a developer for this job.
On a more optimistic note, may I ask what service do you actually use to stream your videos? For example, Vimeo with the cheapest paid plan offers an option that restricts access to your video outside a specific domain name. Meaning you can set that your videos must be streamed only on domain.com, and thus they will be accessible there and only there.
number of user used our website portal for using our service.
Recently we have enable google captcha v2 and its working fine. however some of our clients not able to use our sites b/c there are not allowing internet to their employee and captcha is blocked or its not showing.
they are not convinced to allow internet on their network b/c of their policy but they agreed to allow some custom URl .
any work arround for this scenario.
Its near impossible to make a local call from your server to google, and act as the middle man - to communicate with your client - even if you do that probably google recognize you as attacker.
The solution is very simple, use a captcha from existing free source code in the Internet direct on your site.
Here are some:
https://www.codeproject.com/Articles/5947/CAPTCHA-Image
https://www.codeproject.com/Articles/13209/A-CAPTCHA-Control-for-ASP-NET
yes its near to impossible
however middle ware or proxy server should do the trick
We provide a third-party site to clients. Frequently when we are handling an RFP, we are asked if it is possible to embed our site within our client's site. Many of our prospective clients have unusual limits or requests, such as 'do not use iframes'.
To that end, I've been asked to ensure that our upcoming redesign of our site makes it practical to embed in client's sites in at least two ways.
The methods of embedding a full-functioning website (as opposed to a cross-site image or piece of static content) within another are as follows:
iframe - Much used, frequently maligned, and some of our
previous RFPs have specifically excluded this as a possiblility.
Object/Embed tags - going way back, it's possible to embed a
full-functioning HTML page into another the same way you would embed
a flash object.
Ajax - Supposedly capable of loading a full
site into an HTML object (such as a div tag), but there seem to be additional security hoops to jump through, due to the dangers of cross-domain requests.
Are there other methods for placing a full site within another from a different domain? Are there any caveats or limitations to any of the above three (for instance, our site uses AJAX calls for login and to update some user-defined settings, will those all function correctly in each of the above embed strategies?) that I might be unaware of?
Thanks in advance.
X-Frame-OptionsResponse Header
If you are embedding your site to somebody else's site, you must be careful about the X-Frame-Options response header. Make sure your site does not send SAMEORIGIN as the value for X-Frame-Options. If you do, it will cause problems for iframes and embedded objects. You can do two things:
You absolutely do not send the header: Any site will be able to display your site in an iframe or as an embedded object. This can cause security problems like clickjacking. See this article for more info and defense on clickjacking.
You can make sure only the site you authorize will be able to embed your site: This is done by sending ALLOW-FROM url value for X-Frame-Options header. You can sniff the HTTP-referer to identify which site is requesting your page. This is really secure than option 1 (unless users' browsers are malicious, of course). NOTE: Not all browswers support ALLOW_FROM. See linked reference for supported browsers
Same Origin Policy
Same Origin Policy will not affect you as far as your site and your clients site do not access each others DOM.
CORS
Cross-Origin Resource Sharing should be considered if a script from your clients' website makes an AJAX request (XmlHttpRequest) to the resources in your site. But as far as your question is concerned, this is not the case, I think.
I gave an answer explaining CORS some time back, you can read it if you want to get a basic understanding of CORS.
Plugins for third party sites
It seems like you are trying to embed some functionality in clients site. Consider offering site plugins like those Facebook and Disqus does.
I am not sure if Same-Origin Policy or CORS applies here. I will find that out and get back to you.
Note: X-Frame-Options, Same-Origin Policy, and CORS is implemented by browsers. There's nothing you can do if the users browser does not implement these things, or if the browser is hacked to not respect these security policies.
I just used a great PDF Converter, but I noted that they have a 30 minute intermission between conversions (to get paying customers). So I got curious as to how the restriction might be is implemented; and afaik it doesn't seem to be (solely?) cookie-based.
IP-address doesn't seem likely (wouldn't that block entire NATted organizations collectively?), and using filename would be too blunt. Can Javascript generate hardware-unique info these days? What other other ways are there? What is secure, what is easy to implement and what is just rotten?
I think the problem here is to uniquely identify a client's browser.
Can Javascript generate hardware-unique info these days? What other
other ways are there?
A simple solution (may not be exhaustive) I can imagine, is to consider not just the cookie or the ip address but all possible parameters like
cookies
ip address
browser details
flash cookies and
then those information that can be pulled off from a client's browser via Javascript (which is enabled for most of the browsers and needed by most sites like the one you mentioned) such as plugins installed, their versions.
With all these information, one can identify a machine uniquely on the internet to a great extent.
What is secure, what is easy to implement and what is just rotten?
Personally, I have never implemented this, but it seems quite doable.
Some interesting links that I found during the course of this short interesting research are:
Peter Eckersley. 2010. How unique is your web browser?. In Proceedings of the 10th international conference on Privacy enhancing technologies (PETS'10), Mikhail J. Atallah and Nicholas J. Hopper (Eds.). Springer-Verlag, Berlin, Heidelberg, 1-18.
How unique and trackable is your browser?
Is browser fingerprinting a viable technique for identifying anonymous users?
How do I uniquely identify computers visiting my web site?
Browser fingerprinting code snippet
Flash Cookies, a Little-Known Privacy Threat
excuse me if i will sound little stupid but this thing had confused me to the core and i have been searching like crazy on net with no ultimate answer so i hope some one would shed more light on this matter.
now i wanna create a portal site and my client require that everything should be AJAX'ed so i have been playing with ASP.NET AJAX 4 and client site templating and web service, and of course the performance is great with JASON results, but my web Service code will be Public because anything available to JAVA script is available to anyone so as i read to avoid this i must :
use SSL but this is a portal site and front end should not use SSL
Authentication, will this is fine but for back-end and not front-end as login is not required.
after reading a lot as i have mentioned, i have come to the following pitfalls when using web service with AJAX and hope there is a solution or at least a way to bring more security
DOS:
i have read some articles that suggest you should throttle using IP detection and block this request for a while but here are some of the things i am worried about
will it affect search engine crawlers ?
will the hacker be able to bypass this by using proxy or other mean ?
Session HighJacking:
this is scary i still don't know how this can happen when you are using ASP.NET membership, i thought it is a pretty solid membership system!
and will a hacker be able to steal someones pass through this method?
a way to hide your code or encrypt it:
i think i am making a fool of myself here because i have mentioned that if it is public to java script then it is public to anyone, but my client would not want people to see the code writing logic and function.
Hide Webserivce:
like if you use fiddler you can see in the RAW data the path to for example www.mysite.com/toparticles/getTopArticles(10) again this scares my client and i have tried to disable WSDL and documentation in webconfig but this only blocks direct access to the file and nothing more or am i wrong! is there a way to hide the path to web service?
so all in all my top concerns is to prevent hammering any of my web services and hide my code as much as possible.
so am i to paranoid as on the front end i am going mostly to be pulling Data but again i may give user the option to save for example his widget preferences in DB, etc... and it is not gonna be through SSL thus the above security threats are valid.
i hope some one can also share his experience on this matter,
thanks in advance.
Any functionality exposed on the web is going to be, well... exposed on the web. Even if you were using pure ASP.NET with postbacks, sniffers can see the traffic and mimic the postbacks, Ajax just takes that to its logical extreme. Webservices are (for the most part) just like any other get/post system (RESTful or not).
There are some methods that you can use to secure your webservices from unauthorized access, but in truth these are the exact same things you would do to secure any other site (asp.net, traditional web, etc).
There are lots of articles all over the web about how to secure your website, and these will apply equally well to AJAX, Webservices, etc.
If you are really concerned about your webservices being publicly exposed, you can use your own custom reverse proxy to hide the services inside the customers network and only expose the proxy to the outside world. You can then secure the services so they are only accessed through the proxy and provide whatever appropriate security on the proxy you feel relevant. In this way all traffic comes through servers that you specify and is restricted (to a reasonable degree) from prying eyes. In general though I think this might be over-kill especially for a portal site.
One thing to talk with your client about is the upsell value of using webservices as a sellable product to integrators. In other words, designing the security into the webservices and using the portal only as an example of how to put it all together. A clear example of this is SharePoint, which is in truth a collection of webservices and processes and the website is really just for convenience, the power of SharePoint is in the interop of the services.
For more specific answers to your security questions, there are plenty of posts here on SO as well as the web covering each of your specific points.