so right now I'm writing a Windows 7 Gadget using Javascript (w/HTML) that will grab some information from a page that it needs to log in to. So I have apparently gotten the Post statement to work over the https domain, because now I get a page in the responseText telling me I need to have cookies enabled. Right now I use a ServerXMLHTTP object to make a request, which is comparable to using an XMLHttpRequest object. I don't know that cookies CAN be enabled in a Windows 7 Gadget, so I'm looking for an answer on whether or not they can be, some kind of work around if possible, or some other avenue to take for getting the solution.
Windows Desktop Gadgets do support cookies, but they only persist for the life of the sidebar.exe process — once that closes all cookies are forgotten. However, I did just check and MSXML2.ServerXMLHTTP doesn't store cookies by default, I'm not sure if there are any options you can enable.
Is there some reason you're using ServerXMLHttp over XMLHttpRequest? If you use XMLHttpRequest the site should work fine.
I figured I'd come tie up this loose end, I figured out to post to the server by setting a randomly generated cookie of valid length and setting that as the requestheader for the SXH request. Also necessary was to set the address of the server as the host of the SXH request. At that point it was a matter of posting to the correct url and then sending a valid query.
Related
I'm currently making an open source browser extension that will send requests to my site. This can easily be done with Ajax, a request will be sent to the page action.php.
My site will use PHP, well now the question is, how can I make sure action.php receives the request from the original extension? I mean griefers could easily send false information to the server, or a fork could be used and send incorrect data. I thought of generating a token of some sort, but anyone could recreate it I guess.
How can I prevent this situation?
I have some experience with this myself. I've been building an extension with a login and eventually came to the inevitability that security in an extension is inherently difficult.
The issue is that an extension is just a bundle of JS and HTML that anyone can inspect the values of. This means that anyone determined enough to dig through your code can potentially find out how to bypass anything you have built in.
The solution I eventually came to is that, the extension itself cannot hold any long-lasting secrets. A session with a timeout is the only safe thing to store. The actual login for my extension is done via a website over HTTPS.
If you are trying to do this without any such login, your only recourse is to make it as difficult as possible to determine what needs to be sent by using an algorithm that can generate server verifiable tokens, and then only publishing minified code to the webstore.
EDIT: Reread the question and noticed that you said you are doing this open source. Without some sort of authentication on the webserver via HTTPS, there is little you can do to stop those determined to bypass your protections because they will be on display in your public repository.
For sensitive endpoints like this, it would make sense do to the data processing server-side. The client would only have to query the server to process the data.
When doing a simple request, on python (Entought Canopy to be precise), with urllib2, the server denies me access :
data = urllib.urlopen(an url i cannot post because of reputation, params)
print data.read()
Error:
Access denied | play.pokemonshowdown.com used CloudFlare to restrict access
The owner of this website (play.pokemonshowdown.com) has banned your access based on your browser's signature (14e894f5bf8d0920-ua48).
This is a apparently a generic issue, so I found several clues on the web.
https://support.cloudflare.com/hc/en-us/articles/200171806-Error-1010-The-owner-of-this-website-has-banned-your-access-based-on-your-browser-s-signature:
A firewall, proxy, a browser plugin or extension may be throwing a false positive. Try visiting the site with a different browser as an alternative way of accessing the site.
https://support.cloudflare.com/hc/en-us/articles/200170176-Why-am-I-getting-a-Checking-your-Browser-before-accessing-message-before-entering-a-site-on-CloudFlare-:
The "Checking your browser before accessing (insertsite.com) occurs when the site owner has turned on a DDoS protection and mitigation tool called "I'm Under Attack". The page will generally go away and grant you access to the site after 5 seconds.
Note: You will need to have both JavaScript and Cookies turned on in your browser to pass the check. The check is in place to make sure that you are not part of a botnet."
The answers are rather clear, except for this one thing ... *I'm not using any browser! The request is done trough a python program, with an urllib.urlopen request ...
Does this mean I'm supposed to have, like, cookies and JavaScript turned on in ... Enthought Canopy? Does this sentence makes any sentence at all? I barely understand anything about this browser specific check activating when trying to access the site with a basic request from a programming console. And that's why I ask for your help.
Why does it happen? How to bypass it?
What this site is "checking" is not your browser, it's the "user agent" - a string your client program (browser, Python script or whatever) eventually sends as a request header. You can specify another user agent, cf Changing user agent on urllib2.urlopen.
I just saw it with Safari from my home IP, looking at a site I author! After performing a login to cloudflare website and hitting refresh its back. Probably my mobile internet was too slow (in New Zealand) and the javascript did not load in time? I have DDOS protection and "under attack" enabled AFAIK.
We have a database with millions of domain categorizations (storing it client side is not an option) and we want to make a chrome extension to blacklist sites based on how they are categorized in the Mysql database.
The server side stuff is easy, we post the domain, and return the category.
The tricky part is blocking requests based on the categorization. Here are a few potential implementations and why they won't (quite) work.
Idea 1:
Redirect all traffic using Chrome.webRequest to mysite.com/script.php?url=www.theoriginalurl
This script checks the database's category & either redirects them to the theoriginalurl.com or denies the request, redirecting them to www.youGotBlocked...
Have the chrome extension check the http referrer header to make sure that they came from mysite.com (unless the url is mysite.com, then do nothing).
Problems:
It doesn't seem like we can set the referrer header in PHP, so we have no way of knowing that they came from mysite.com. It seems like maybe we should be passing info via a cookie, but I haven't thought of an elegant solution involving cookies.
Idea 2:
Every time Chrome.webRequest fires make an AJAX POST request to mysite.com/categorizeURL.php with the URL to get the category. Block or allow based on the server's response.
Problems:
Either we make the request asynchronous and we can't get the response in time (their is no way that we have found to delay the callback until the server responds -- more on that here). Or we make the request synchronous, and IT WORKS!!! Except for the fact that if they can't reach our server, their entire browser locks up and they essentially need to refresh the extension to be able to access the internet again.
Other ideas?
Does anyone have other ideas for creating a blacklist via a Chrome extension? I simply refuse to believe that it is not possible.
I run a site A and I want to be able to POST data to site B, which is hosted on a different subdomain. Now I have complete access to A, but cannot modify B at all.
My requirements are:
supports file upload
does not refresh browser on POST
uses Windows integrated security
works in IE 7/8 (does not need to support any other browsers)
What's the best way to accomplish this?
What I've tried:
Ideally this could be done in a simple AJAX call. However the current standard does not support sending binary data (supported in the XMLHttpRequest Level 2 standard, which is not implemented in IE yet).
So the next best thing is to POST to a hidden <iframe> element. Now I've tried this but the server on site B won't accept the data. I looked at the request and the only discrepancies that I found were the referer URL and the integrated authentication. The referer URL might have to be spoofed, which cannot be accomplished by this method. Also for some reason the authentication isn't being negotiated. I'm not 100% sure why.
Ideas:
I'm thinking of creating a proxy page on the server that I run (site A) that forwards the request to site B. Site A also uses integrated security. I don't see anything wrong with this, but I'm not sure if this is the best way to go. Will there be any authentication issues if I just forward the request over?
Using a proxy seems to be the only thing which can work in your case. If you want to make a get request then it can be done using JSONP provided that the server supports JSONP. To make the <iframe> hack work the server should send the headers as
Access-Control-Allow-Origin:*
which is not the case with you.
So using a proxy seems the solution
The way to delete cookies in javascript is to set the expiry date to be in the past. Now this doesn't actually delete the cookie, at least in Firefox. It just means the cookie will be deleted on browser close.
This is a problem for us: we have a product that involves archiving web pages from potentially many sites, with all this content stored on our server. And to make sure that pages render properly we include all js as well. However often cookies are set by js, and given that the page is cached on our server, these cookies are set under our domain.
So over time cookies from dozens of archived sites build up under our domain. And eventually the Cookie header exceeds the max content length, resulting in an HTTP 400 error code.
And because our clients are mostly in corporate environments they never reboot their machines or close their browsers: they can be left on for months. So this "soft" delete doesn't work, at least not reliably.
Is there any way to physically remove cookies intra-session in javscript? Or alternatively, is there any way to stop them being set?
It's not possible. Period. I've been struggling with this for several weeks without finding a solution.
Whoever invented the cookie getter/setter should be %insert_painful_punishment_here%.
Particularly Internet Exploder is a beast when it comes to deleting cookies. I can't remember the exact issue, but I think it involved https and cookie names containing ;.
All I can offer is a workaround: Send a response body with your 400 response, something like 'please restart your browser'.
In addition to setting the expiration in the past, set the value to an empty string. This will at least reduce the size of the cookie immediately.
I would think that cookies should be deleted immediately in all browsers. For example, when I log out of a website, Firefox does not require me to close my browser to delete the cookie that shows that I am logged into the site. If this isn't happening, I suggest you look into Firefox bugs and possibly open a new one with them.
In the meantime, I'd look at my web server and see if it is possibly to set the max content length to something higher than it already is.
You could overwrite the cookie with a new one.
"It is because we are NOT using iframes that we have this issue. The cached page is being rendered by our server, so any cookies get set under our domain." --OP
If you have no control over the javascript that is setting the cookies (which seems extremely odd, why do you not have control?), you can constantly read and empty the cookie, dumping the data to another larger database (preferably server-side, or perhaps HTML5 client storage).