any hint on browser security behavior and new gTLDs ?
I mean, for a brand gTLD, is it possible to set a cookie for *.brand, to allow Ajax requests on *.brand, ...?
Best regards
Related
We're looking to do some scraping on a specific URL that uses cloudflare. Has anyone experienced issues using Zombie.js/user-agents while trying to crawl cloudflare hosted sites.
Would love some help!
I am trying to interface to an API on a client's site and I am getting a 403 error indeed. The request doesn't even reach my server.
Turning security to "essentially off" did not help. The final solution was to white-list the developer machine's IP.
The error is triggered on a single URL (json serving API) with a Java client with standards compliant libraries.
Solution:
1. try to set a rule to allow direct access for that URL
2. try setting security to weaker and weaker ("essentially off")
3. if both fails: try whitelisting
4. set up an alternate non-cloudflare url (direct.domain.com)
These will of course only work if you can negotiate with the site owners.
Backup solution: use an embedded browser that you can "frame" and "remote control" or a testing framework that does the same through a plugin, and extract the content from there (if you can)
Hope this helps.
You're probably triggering one of our security features by trying to scrape a site on us. The only option, really, would be to ask the site owner to whitelist your IP(s) to override the behavior.
Hello I would like to implement a payments on my web site.
I have a requirements that to do it in iframe with hidden address bar.
But in this case user would't be abble to see that we are using HTTPS protocol for sending data and e.t.c
Does is it good practice or it is looks like security issue ?
I don't think it is a good idea to hide HTTPS information from end users. If you look at any web security for dummies kind of guide, they all say that when you enter private/financial information etc make sure your address bar display the lock etc.
Even though you may in your HTML that you are using HTTPS, do you really expect users to "view source" your HTML and/or use Fiddler etc? No right?
So, do the right thing- show HTTPS URL.
BTW, from security perspective, if the first page you serve is NOT over SSL, someone could just modify HTML and inject a malicious HTTPS link with valid cert. That is why it is very important to have SSL enabled on your whole website.
No wonder HTTP 2.0 is going to be all SSL :)
Technically you don't need HTTPS if you are using iFrames for checkout. Ofcourse the 3rd party website is always protected... BUT since you cannot explain this to your customers/clients, so you have to have a HTTPS even you are using iFrames even it is secure but to make your customers feel actually that they secure you should have SSL (HTTPS).. Or I know many of your customers will simply leave your website... SO YOU DO NEED IT... YES
I want to enable cross site scripting for some sites. Specifically, I want to submit a web form to a 3rd party site, I have set the target iframe for the web form's response to a child iframe, now I want my code in main window to retrieve content of the response web page.
Am I correct in assuming that I can do the above by simply disabling the XSS Filter in Internet Explorer? Or is something else also required? Also how do I enable cross site scripting in Firefox (for the same scenario?)
IE's XSS filter does not protect against DOM Based XSS. So in order to execute a javascript payload across domains you can simply run eval() the request variable or use document.write().
A more common approach is to use a "cross-domain proxy". Mainly because this approach usually doesn't introduce a gaping vulnerability which could be used to attack your users.
Am I correct in assuming that I can do the above by simply disabling the XSS Filter in Internet explorer?
No. The XSS filter isn't responsible for this limitation.
Or is something else also required for the same?
There is no way to enable cross-origin requests from within a web page -- restrictions on cross-origin requests are a fundamental part of the web security model. However, for development, you can launch Google Chrome with the --disable-web-security flag to allow you to make cross-origin requests. This can be helpful in development of web applications where the application must access an API hosted on another domain.
Hi I have recently read JSP and came across its technologies, mainly session. Under session, I read URL rewriting one of the method that was been done in order to maintain the session with the client. But since the URL rewriting changes the URL with the session ID and it can be visible to the client.
Is that not a security issue? Lets say for example, if any one note this session ID apart from the particular user, and can make a bad use of it? Or else there are techniques for preventing these?
Correct me if am wrong.
Certainly this is a security concern. If you quickly take note of the jsessionid value, either from a by someone else mistakenly in public copypasted URL or a in public posted screenshot of some HTTP debugging tool (Firebug) which shows the request/response headers, and the website in question maintains users by a login, then you'll be able to login under the same user by just appending the jsessionid cookie to the URL or the request headers. Quickly, because those sessions expire by default after 30 minutes of inactivity. This is called a session fixation attack.
You can disable URL rewriting altogether so that the jsessionid never appears in the URL. But you're still sensitive to session fixation attacks, some hacker might have installed a HTTP traffic sniffer in a public network or by some trojan/virus, or even used XSS to learn about those cookies. To be clear, this security issue is not specific to JSP, a PHP, ASP or whatever website which maintains the login by a cookiebased session, is as good sensitive to this.
To be really safe with regard to logins, let the login and logged-in traffic go over HTTPS instead of HTTP and make the cookie HTTPS (secure) only.
URL rewriting of session cookies is discouraged in most (if not all) security circles. OWASP ASVS explicitly discourages its use as it results in exposure of the session identifiers via an insecure medium.
When URL rewriting of session cookies is enabled, the URL could be transmitted (with the session identifier) to other sites, resulting in disclosure of the session identifier via the HTTP Referrer header. In fact, a simple request by a browser to a resource located on another domain will result in possible hijacking (via a Man-In-The-Middle attack) or fixation of the session; this is as good as a Cross Site Scripting vulnerability in the site.
On a different note, additional protection mechanisms like the HttpOnly and Secure-Cookie flags introduced into various browsers for protecting the session cookie in different ways, can no longer be used when URL rewriting of cookies is performed by a site.
I believe you're referring to cookieless sessions. Although I have seen it referred to as 'url rewriting' in Java circles.
There are some extra session hijacking concerns (and they apply across all web development frameworks that support cookieless sessions--not just JSP). But session hijacking is possible even with cookies.
Here's a pretty good in-depth article on MSDN about cookieless sessions and the risks/benefits. Again, these are all platform agnostic.
http://msdn.microsoft.com/en-us/library/aa479314.aspx (toward the bottom)
This is what I came accross checking the OWASP specifications for URL rewriting and it Exposing session information in the URL is a growing security risk (from place 7 in 2007 to place 2 in 2013 on the OWASP Top 10 List).
Options for managing URL rewriting include :
disabling them at the server level.
disabling them at the application level.
An attractive option is a Servlet filter.
The filter wraps the response object with an alternate version, which changes response.encodeURL(String) and related methods into no-operations.
(The WEB4J tool includes such a filter.)
We have our site integrated as an iframe into another site that runs on a different domain. It seems that we cannot set cookies. Has anybody encountered this issue before? Any ideas?
Since your content is being loaded into an iframe from a remote domain, it is classed as a third-party cookie.
The vast majority of third-party cookies are provided by advertisers (these are usually marked as tracking cookies by anti-malware software) and many people consider them to be an invasion of privacy. Consequently, most browsers offer a facility to block third-party cookies, which is probably the cause of the issue you are encountering.
From new update of Chromium in February 4, 2020 (Chrome 80).
Cookies default to SameSite=Lax. According to this link.
To fix this, you just need to mark your cookies are SameSite=None and Secure.
To understand what is Samesite cookies, please see this document
After reading through Facebook's docs on iframe canvas pages, I figured out how to set cookies in iframes with different domains. I created a proof of concept sinatra application here: https://github.com/agibralter/iframe-widget-test
There is more discussion on how Facebook does it here: How does Facebook set cross-domain cookies for iFrames on canvas pages?
IE requires you to set a P3P policy before it will allow third-party frames to set cookies, under the default privacy settings.
Supposedly P3P allows the user to limit what information goes to what parties who promise to handle it in certain ways. In practice it's pretty much worthless as users can't really set any meaningful limitations on how they want information handled; in the end it's just a fairly uniform setting acting as a hoop that all third parties have to jump through, saying “I'll be nice with your personal information” even if they have no intention of doing so.
Despite adding SameSite=None and Secure in the cookie, you might not see the cookie being sent in the request. This might be because of the browser settings. e.g, on Brave, you have to explicity disable it.
As more and more people are switching to Brave or block third party cookies using browser extensions, you should not rely on this mechanism.