I just implemented uploadify in my project, and I noticed what seems like an important security issue with the uploading process:
The folder in which the file should be uploaded is provided as a javascript argument, so client-side. If the user changes the script, and fills in a different folder (i.e. "/") for the upload, the file gets uploaded to the different folder.
There is an option in the config to filter the filetypes, but again it's provided on the client side ("fileExt").
So am I wrong to think this could lead to a possible hack? Uploading a php file anywhere in the Web Root and executing it seems easy.
Is it the desired behavior?
Should I just cross-check the upload folder in the uploadify.php file?
Should I send a notice to the uploadify makers?
I'm sure I'm not the first one to think about this. Oh, and the same goes for other config parameters, like sizeLimit and queueSizeLimit.
Just looked at the code (haven't installed it anywhere), and it certainly looks like this is a security problem. Looking at uploadify.php, I see this:
$targetPath = $_SERVER['DOCUMENT_ROOT'] . $_REQUEST['folder'] . '/';
Which means that passing "/" would put the file in the document root (i.e. the home directory of your website). Of course, the user could easily (for example) pass in a folder parameter like '../../etc' and a file named 'passwd'. Or, more trivially, he could upload a "logo.jpg" to the document root and, hey, now you've got porn for a site logo!
Of course, even if you sandbox the users, there are still lots of potential problems with allowing a user to arbitrarily upload a file to your server. What if they upload a .php file, then go to that file with their browser? They suddenly have the ability to execute arbitrary code on your server!
If you want to do this, you should force the user's uploads into a restricted directory (the realpath function will sanitize the path, in case the user created crazy paths with "../.." or whatever), and you should restrict the types of files allowed (i.e. to only ".jpg", ".gif", ".png" or whatever). Even then, a malicious user could DOS you by filling up your disk quota.
i just want to give my opinion about your post.
You forget a important thing in your analyse.
Developpers HAVE TO check variables in the server side script.
If you use javascript (like uploadify, or your own script) or if you don't use javascript (just a simple FORM in html), YOU HAVE to check the data in the server side script. So no matter if you are using uploadify or not for your security. Don't forget that it's easy to buid HTTP request and send it to the server. So the security of a web application not depends of the client
Thanks for your attention
GUIGUI
That is indeed a security issue, path traversal. You should email them and ask them to fix it.
You are free to put file anywhere using your server side script and your config. I never use their javascript config for such things.
I know this is a bit old topic, but here's a note from plugin developer:
Given the wide variety of scripting languages, server side validation is up to the users to code. We are developing the plugin to allow those who know what they are doing to use what ever language they want for the front end and back end. And creating new scripts to retrieve information makes it that little bit harder for other users to implement, for example those using aspx, java, codeigniter etc.. would need to rewrite major portions of the plugin.
You can read it full here.
Remember, server validdation is a must! You cannot ignore it, ever. This is what I've learnt reading SO and PHP manual.
Related
We're talking to a 3rd party to include some of their data on a website of ours, they want to do it either through an iframe which I don't prefer because of responsiveness reasons.
The other options they offer is the inclusion of a javscript file which will take a parameter to know what DOM element to put the results in.
Basically this gives them access to the javascript scope of our website in which if they wanted can do stuff like hide dom objects etc.
My question is, are there any security things I have to think off? Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc? Or is the only thing they can do DOM related?
They could:
Take control of users' cookies, including reading and modifying
them.
Redirect the user to any site they would like.
Embed any code they would like into the page.
They can't:
Access php files directly.
Access any server files directly.
Javascript runs in the browser and not on the server.
You're essentially giving them trusted XSS privileges.
If you can do something in a web browser (make posts, "browse" a page, etc), you can automate it using JavaScript. They won't be able to upload/modify your PHP files unless you (or your users) can.
To the user, you're giving them to capability to impersonate you.
To you, you're giving them the capability to impersonate users.
Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc?
They can do anything in the JavaScript code you're including on your page for them that you can do in JavaScript code on that page. So that could be just about anything you can do client-side. It includes (for instance) grabbing session information that's exposed to your page and being able to send that information elsewhere.
If you don't trust them not to do that, don't include their JavaScript in your page.
We're talking to a 3rd party to include some of their data on a website of ours
Have them make that information available as data, not code, you request via ajax, and have them enable Cross-Origin Resource Sharing for the URL in question for requests from your origin. Then, you know you're just getting their data, not letting them run code.
Note that using JSONP instead of CORS will enable them to run code again, so it would have to be true ajax with CORS if you don't trust them.
You shouldn't have to worry about PHP files, or config files but stealing session cookies or other XSS-style attacks could definitely be an issue.
Why can't/won't they provide data in the form of an API?
Consider a dynamic website running an application, where you can see the URL from your browser as:
www.example.com/game
Now the /game is probably a folder? And how can i see the actual path to the application?
Can't I see the server side scripting language, such as:
www.example.com/game/robobo.php or
www.example.com/game/robobo.aspx or something similar?
Now, I know you can guess some of these (typically with the "index" name), however there may be many subfolders.
Now the /game is probably a folder?
It is part of the URL. That's all you can know about it.
And how can i see the actual path to the application?
You cannot.
How the URL maps on to the server's file system (or even if it maps on the file system at all) is not information that the webserver will expose.
Can't I see the server side scripting language
Not really.
There might be fingerprints in the HTTP response headers that could clue you in, or HTML returned in the response body might include fingerprints from a particular CMS which would imply a programming language, but there is nothing certain.
This is not possible. When you think about it, dealing with a blind url like .../game, you have no idea whatsoever what the underlying platform is - might be Asp.Net, might be classic Asp, might be PHP - might even be Python or Ruby... Since you don't know what system sits on the server, you are not going to be able to know what to do to get the full path...
Most CMS systems allow the website owner to change the true URL to something more user and search engine friendly (sometimes called Permalinks or SEO URLs). /games, does not mean that there is such a folder, it could be a category name or a tag. The only place where you can see full paths is for media assets such as images and videos. (right click, view image source or open image in a new tab).
Unless you are the admin of the website, it is nearly impossible to find the real path.
I am saying nearly impossible since you already pointed out on guessing.
The server side is obviously hidden from visitors.
You can guess what is the technology used on a website by testing it on other websites such as builtwith.com.
For example if it shows php, then there is a great probability that all files end with .php.
I am trying to make a sign up activity on android and I am using a mysql database to store the data. On all the examples I have seen the http post goes to a ip address and then finds the php file. Can I just put the php file somewhere in the android app folder and access it from there, or do I have to find a host for it?
The php code, specially for tasks such as sign up, should never be placed on the client side or embedded with the front end application, but instead be placed on the server side hidden from the user for the sake of safety of your database/application. If you are only considering to put your php with your Android app together for the case you need to test it, and eventually doesn't have access to a server, you may then consider using Google App Engine, as it allows you to emulate a server locally without the need of a server. Here you find some info about Amazon's RDS.
You can put you php in the same directory you place your index.html file, i.e. in the root public directory of your domain. To load it to the Amazon, you can use the cPanel or the Filezilla or any other panel you wish among the options Amazon put available for their users.
In the case Amazon doesn't provide a place to put your php, as a suggestion, you can get a host that allows you to have a static ip accessing it thorough an easy to remember url address - for free. It is quite useful specially for making tests. Still if you decide at some point to have a personalized domain name registered, there are also some other good options to compare.
You dont need jQuery, when doing the POST request,PHP connects to the database get the data and return it to your app.
So to answer your question you should put the PHP in the same server where mysql runs.
No matter how much I look this up all I get is the w3C File API which focuses on local files for the client.
What I'm trying to do is I have a server. I'm trying to use client-side javascript to grab the server hosted text file, a.txt, and display it to the innerDOM of an html page. My server directory look like this:
index.html
read.js
text files
a.txt
All I want to have happen is for, on the client side, the javascript read.js running in the index.html on onload to display the contents of a.txt. I figure that since a.txt will never be large, leaving it to the client is fine.
But I can't figure out how to do this and the W3C File API isn't offering me answers.
If I had to guess, somehow making sure index.html loads a.txt and then grabbing that via the file API might be the way to go but I'm not sure how to do that.
And I'll admit it, I'm a bit of a noob. If I'm invalidating browser sandbox or doing something impossible, please tell me. I just thought this would be so simple.
Also, I'd appreciate that if you were going to suggest AJAX, either don't, or explain it like I'm a baby because I really don't know.
Thank you all so much for your help.
Why file API is irrelevant:
Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application.
From W3C File API.
So, File API is intended to be used to allow users to upload files from their clients into the server. On the other hand, AJAX is used to allow users to download files and other data from the server into their clients. And this is exactly what you need.
Refer to jQuery's ajax documentation.
I believe this page should help you out with your problem.
http://www.htmlgoodies.com/beyond/javascript/read-text-files-using-the-javascript-filereader.html#fbid=YhNukIHynD3
I would suggest using an Ajax call to the file on the server, since the response of the call will typically be the contents of that file.
Using Jquery this can be done by a simple
$.ajax({ 'url':'a.txt',
'success': function(r){
//display to innerDOM here, using r as the file
});
});
You simply want to display a txt file on the web page?
Do you know about server side includes?
That would be one possibility if you control the server.
If you really want to do it in javascript, then AJAX would be the way to go.
If it were me at that point I would figure out how to include and use jQuery to help with the ajax bits.
You will simply request the text file via its URL (you can get it to load in the browser right?), and then use jQuery to put that text into some DOM element.
Theoretically JS runs in the browser, then after the first download can be easily copied and made to run directly from the local, without going through the remote server. Because I need to sell an application * js (pay-as-you-use) I need to check each request and make it available ONLY if required by that particular site and, of course, only if he paid.
It doesn't work. As soon as someone downloaded a copy of the JavaScript file, he or she can always save a copy of it and even redistribute it.
Thus you cannot protect the JavaScript itself - but assuming you rely on some client-server interaction (i.e. AJAX), the server would not respond to requests coming from non-authorized sources, thus rendering the client-side worthless.
If you need to protect your business logic, don't put it into JavaScript. Alternatively, sue everybody who uses your scripts without having obtained a license (not sure if this is practical, though ...).
I wouldn't make the JS file that you plan to sell available directly on a URL like
yourdomain.com/yourfile.js
I would offer it on a URL like
yourdomain.com/getfile
Where /getfile is a URL that is processed by a PHP/Java etc server-side language where you can check whatever credentials you need to check, be it requesting domain name, IP address, some token or something else.
if your application is made in java you can use a ServletFilter to check if the request is valid (if the IP is correct, or maybe you can use a ticket like the facebook, twitter, whatyouwant rest API), and if isn't valid don't show nothing
if you aren't using java I think that something similar can be made with every programming language
It may be a little more trouble than it's worth. Yes, you could require clients to provide a token and whitelist certain domains, etc. But they can still open any site that uses that particular JavaScript -- even someone else's -- and just Save As... .
A better bet is controlling the script's interaction with your server. If it makes any AJAX calls a server you control, then take that chance to authenticate. If it doesn't depend on data from you in that way, I think you'll just have to face the problem that anyone dedicated enough will be able to download your script and will be able to use it with a little bit of playing around.
Your best bet is, in addition to the above, keep track of domains that have paid and search every once in a while to find if anyone's taking your code.