Slashdot Mirror
TinyDisk, A File System on Someone Else's Web App
Psy writes "I attended Phreaknic this weekend where Acidus released TinyDisk, a shared file system that runs on top of TinyURL or his own implementation NanoURL. TinyDisk compresses a file, encrypts it, and dices it into clusters. Each cluster is submitted to TinyURL as if it were a url. This clusters can be read back out of the database, making TinyDisk a global file system anyone can use. There are safeguards in the default config to prevent people from dumping gigs of MP3s into TinyURL. While file-system-on-web-applications are nothing new (GMail file system anyone?) this hack shows how easy it is to accidentally design a web application insecurely despite the default PHP protections. See his presentation for more info"
Nifty little program all the same and a nice hack ,
Having it running on his NanoURL implementation locally , could allow for a cool little service . Though there are better ways to offer web based file systems in the real world .
He does state in the FAQ that its not intended to pollute TinURL in any way
Perhaps it will give TinyURL a nudge to tighten up their security though .
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Pretty soon you'll see someone trying to use this as their backup system for 30gb of pr0n. Will large files kill TinyURL? What kind of latency is this going to introduce? If nothing else, this might constitute a DoS attack on TinyURL.com (which would be illegal.
It's still interesting work.
$nice = $webHosting + $domainNames + $sslCerts
Gmail Filesystem
That's pretty much what I understood.
I adore the ingenuity (correct spelling?) of the hack but... I can't really find a problem this hack is a solution for.
As a way to distribute files, it's probably too slow. The pro's I see here: the file is not stored as one single file but it's stored as a distributed file (a set of Base-64 encoded clusters), making removal of the file hard. On the other hand, if one single segment drops out, the file will be destroyed (except if some redundancy exists, of which I did not find evidence).
If you want to send attachments in an e-mail, this is a very complicated way to do it. Every receiver must have the decoder program to re-assemble the file.
Moreover, if tinyURL builds in a check to see whether the submitted URL exists (not just some 404 page), the whole concept would probably break.
Anyways, very clever hack!
--Use ant to make
I noticed that the whole of Alice in Wonderland is compressed to just 20 clusters and each cluster is represented by the five-letter keys used by TinyURL. So is it not possible, using the same method, to reduce the entire metafile (which is merely a textfile of less than 1kB) into a single-line URL? Then you can have the program retrieve the metafile from the URL and the actual file from the metafile. So instead of sending people a metafile, you can just copy and paste them one line of URL.
not really. as the author of the hack already proposed, you can add hosts of sites that have base64 encoded urls which means that you can get http://www.bleh.org/topic.php?= and then the prog will filter out the part for use in the decrypting... surely if you use big enough sites (amazon, google, again as the author proposed) you can circumvent this. The point of this "hack" isnt really to show how to break tinyurl but to create a different way of approaching networked file systems, using only HTTP POST/GET. I for one see great potential in this for the likes of Al Qaida (you know, where better to hide your building hitlist than on tinyurl).
Take the list of cluster URLs. Concatenate them into a single URL. Submit it again. Thus compressing literally ANY file to five characters.
At least, as long as the possibility space of five-character URLs isn't exhausted. It's very much first come, first served.
qntm.org
PayPal UK used to use the same technique to validate you were the owner of a credit card: make a small reverse payment and ask you how much it was. Then they got proper integration with the banks and stopped doing it like that.
And WTF is this modded 'offtopic'?
Yes, I RTFA, and looked at how things work, the fact that PHP is being used is immaterial.
The basic functionality of TinyURL, NanoURL or any other service is to accept a string (presumably a URI) and return a shorter string that will serve as a pointer to it. If you want your application to accomplish that it doesn't matter what it was written in, people can store things other than URLs in your database. The protections against this sort of use/abuse suggested in the article are also language independent.
paul reinheimer
I had a similar idea a number of years back basically masquerading uuencoded files inside of bogus html files that get crawled by Google's caching bot... the idea being that if you knew the names of the files you could query the cache and retrieve the UUEncoded bits.
At the time, no one else had written about such things. I just never got around to automating the process, so it never really materialized. Maybe some brave and time-rich soul would like to give it a go?
"This above all, to thine own self be true"
Interesting idea:
(1) create one tinyurl which contains encrypted data
(2) create another tinyurl which contains the decryption key
Never access them from the same IP nor around the same time, and nobody will ever know what you're hiding.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive