Let's say I am making a webserver which reads files from my system.
I have a root directory, say ~/Public and users can request any file in there (or in subfolders.
So I'd do something like File.read(File.join(RootDir, params[:path])) and then send that onward to the user.
The problem is there's a clear security risk here. If the user gives a path like "../../secret_file", they have left my ~/Public folder and can read pretty much anything from my system - obviously, a bad thing.
I'm thinking about how I can do this safely.
The easiest thing is to do just strip out ".." from any user-supplied paths. Would this suffice or is it still risky?
The other option is to use Nginx or some other static server which already has this functionality built in. But I guess, they are doing the same preventative measure I need to here, so why can't I just do it myself?
Related
I'm writing a tool with a GUI for OS X that is launched by the user only when needed, e.g. to delete locked files.
To enable the deletion of such files, root level access to the file system is sometimes required.
Currently, I solve this in a very simple way: The app relaunches itself using AuthorizationExecuteWithPrivileges. That leads to asking the user for an admin account and password. If he does that, the app runs as root and can perform its file access tasks as needed.
The problem with this solution is that it's fairly unsafe and bad style (the entire UI runs under the root user, for instance, which is clearly not desired). Furthermore, AuthorizationExecuteWithPrivileges is now deprecated.
How do I improve this? It's it clear to me that I need to write a helper tool for performing the file operations.
I do not want to use an installer, nor do I want to permanently give the helper tool root permissions in any other way. Instead, I want to require the admin to authenticate the operation every time, just like the Finder requires a user to re-login with an admin account whenever protected files are deleted or modified.
That means that the helper should get root permissions only temporarily. If AuthorizationExecuteWithPrivileges wasn't deprecated, I'd simply invoke the helper tool through that function, and I'd have my solution.
This means that SMJobBless is probably not the right way to go for me. Neither is launchd, it seems. What else is there?
Further question: What kind of inter-process communication should I use? Basically, I need to invoke the helper, passing some file refs (paths or URLs), and wait for it to return the results (including error msgs). I've found various ways for IPC, and I am more confused than ever now. Many reference launchd processes, which probably doesn't apply to me, so what should I look into?
I have searched in all my files for what could be re-directing or putting this malware into my sites to no avail. Anyone who has had this before? Its spread across multiple sites I have hosted. The common component with them is jevents but even the codes for that have not been changed.
Is there a way I can block these requests from .htaccess?
You really need to take your site offline - actually remove the files from the server and identify what type of hack this is.
First though I would suggest turning off javascript in your browser and visiting your page - do you still get redirected?
If not - then the problem is either:
a) a javascript file has been added to your site - or an existing javascript file has been edited. Examine all the .js files loading in the page.
b) an sql injection has added javascript directly into your articles (perhaps each and every article
Assuming you ARE redirected while is javascript turned off - then you are looking at either:
a) an edited .htaccess file redirecting you elsewhere
b) an edited (or 'included') php file setting headers and taking you elsewhere.
Are any of the add-ons in your site(s) listed here:
http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=joomla&filter_exploit_text=&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=
You need to know whether it is only your site compromised or whether it is other sites on the server, or even whether the server itself has been taken over, and that is a question for your host. Immediate re-infection after rebuilding from a backups could mean:
a) a cron job has been set up to re-infect you at a set period
b) another account on the server is infected and is reaching out to re-infect others
c) your site was compromised previously (dropped files within the site) but that these are sat dormant waiting for either an individual or a botnet to connect and take control.
d) or that the server is totally compromised and the hacker just reconnects to re-infect
There are some steps you could take - but frankly this is one area where if you need to ask it is probably a sign you aren't equipped to deal with the issue without expert assistance.
You could grep your files for likely file patterns c99, r57, web shell, eval(base64decode(, etc.
You could scan for files with recent creation dates or recent modified dates/times
Files changed in the last x days (1 days in this case)
find . -mtime -1
Files changed between two dates
find . -type f -newermt "2010-01-01" ! -newermt "2010-06-01"
You should scan log files for suspicious activity
You could download the files and let your anti-virus program scan them - this can give you a place to start (don't let it delete the files though as their contents can give further clues).
You should block access from known automated / scripted useragents (wget, libwww, etc)
All in all though you could spend days battling this with no guarantee of success. My advice would be to get some assistance from a Joomla security expert.
For your next installation, you might want to consider installing also host-based intrusion detection system OSSEC. It offers several security features, including File Integrity checking which would have detected the tampering of your .htaccess files. OSSEC is free and open-source.
You'll probably have to really compare directories and if you can, the original installations of the extensions you used. Check directory permissions - if you see something with 777 or unusually high permissions then that could be a good start to where the problem may be originating from. Check error logs too that may point to something missing or something that has changed and is now throwing an error.
You want to try and identify the problem/malware/virus because it will help you with the next part.
Find the last backup before you were hacked that is a good valid copy, and go from there. Best bet is to completely get rid of the current site and restore from backup (fully) - assuming the backup doesn't contain the virus/malware.
Sometimes there will just be one or two lines of code added to existing lines of code that cause the redirect - these are tough to trace down and identify, but you can do it if you compare sizes and such. Just time consuming. I hope this information helps - good luck.
Also, it sounds like your whole server is compromised if it's spreading - do not use the same password for multiple sites, or the default username (admin). Always change the passwords and the username. If you leave the username default as 'admin', hackers already have 50% of the login figured out. Make it tough on them by changing the user name. Alert your host you've been hacked - they will help in these cases, and can keep it from spreading any further than your account. Change your passwords with that host, change the passwords for each site (preferably after you've cleaned the malware/virus).
I experienced this same .htaccess hack on my shared hosting account. I had 5 sites running Joomla! v 1.5 <---> 2.x. After hours of experimenting with permissions and every other conceivable way to thwart the malicious .htaccess files from regenerating, I found that two of my live Joomla! installs had mysterious .php files in the 'tmp' directory [joomla_root/tmp]. One file was named something like 'jos_AjnJA.php' and the other file was 'j.php'. I changed the permissions on those two files to 000, then once again restored my original .htaccess files to their respective folders. Presto! The .htaccess files finally did not get maliciously rewritten within minutes, as before. 24 hours later and everything is still working as it should on all my Joomla! installs.
I cannot stress enough: I am sure there are variations of this exploit, but do yourself a huge favor and first check all tmp folders on your Joomla! installs for any suspicious .php files!
I'm building a website (hosted on GoDaddy) that will display graphs and charts about data obtained via another website's API. The other website updates its data only once a day, so I only need to make an API call once a day to get up-to-date info. Here's my plan:
A Ruby script on my hosting server's filesystem does the API call, and saves relevant info to .txt files on that local filesystem.
Another Ruby script generates a whole bunch of PHP files based on a bunch of different slices and dices of the data in those .txt files. (The PHP files are what process user requests)
Both of the above scripts are run as cron jobs, once per day.
To rephrase my question: Where do server-side scripts, which are agnostic toward user requests, get placed on the website's file system, specifically if a user is never supposed to see them or even really know they exist? (Or am I mistaken in assuming a setup like /ruby/script.rb is bad practice because people could directly access that file via a web browser?)
Or is my whole approach to this fundamentally flawed? I should clarify that I'm doing this project to teach myself Ruby and learn more about web development.
Under /srv if placed by the sysadmin, in /usr/share/<appname> if packaged up.
When they're for your use only it's up to you. For commands that run on the command-line, I usually put them in ~/bin. Shared files used by them go in ~/lib, or you can create a subdirectory of bin for the lib files: ~/bin/lib.
Files/apps under development usually go in a ~/dev or ~/development directory.
My google search has led me to here: How to create a virtual file?
In that article, people suggested the author to extract the file to a temp directory and work with it from there.
Actually, what I would like to do, is something similar to what the author was originally asking - create a "virtual" file and assign a "path" to it, such that would be understandable by other applications calling standard windows filesystem API. The purpose of this is to prevent copying and unauthorized use.
A concept of what I would like to do:
In our company, we have developed a program - but it's not a standard EXE application, it has an internal format (let's assume the 'application' format's extension is .MDL) and is executed by runtime environment, so the runtime must be installed on the client machine. This concept is similar to Java (although this is not java; just comparing, so that you can better understand). What I want to do now, is to encrypt this .MDL file and include it as a resource in a regular .exe file. This .exe file would check if it's okey to run (check license conditions, keys, authorization etc...) and then, if authenticated, decrypt and extract the .MDL file, exec the runtime and pass the virtual path of the .MDL file as an argument to the runtime.
For obvious reasons, i don't want to write the decrypted .mdl file somewhere on the disk, because somebody could just start the application, wait for the decrypter to write .MDL to temp, copy it from the temp and distribute it.
So, any idea how to do this?
PS: I've got inspired from EA Games' games... when you run them and look into your process table, you see a regular game's exe, and, after certain time, it spawns a new process with name like ~A003.tmp
You should use boxedapp packer. It must help.
I am not aware of any method to have a virtual file associated with a path without using some kind of driver component; that is hard work.
Why don't you have the runtime do the decryption? Then you don't have to worry about decrypting the file on disk. Or you could create an unnamed inheritable section object to which to decrypt the item and pass the handle value to the runtime as a command line parameter.
Whatever you do, people will still be able to bypass it so it seems like a waste of time to me. Every EA game ever made has been cracked; people will either think your product is useful and worth the money or they won't. I don't think it is worth the time or effort to implement schemes more complicated than a very simple registration key check (just to make it look like you did something).
Simple question, but I can't seem to find the answer anywhere. Is there a way in Windows, or via a third-party utility, to enforce file naming conventions within a Windows network share?
I'm sure this is easy in Sharepoint, but I want to be able to limit users to the file name format they save into a folder. I could create a post-save program to go and look for exceptions after the fact, but I want to try and force the user to name the files according to our standards when they save.
If something is not available/configurable on the server-side, could this be accomplished via VBA in Excel or Word in the save-file dialogue?
Thanks for your help.
A
There is nothing, to my knowledge, that can restrict file names.
Nothing unless you write it yourself.
How about monitoring the folder for changes and as soon as a file with the "wrong" file name is created you alert the user in some way?
Idealy you'd want a "hook" of some sort on the file system level that will also let you fail the file operation if the filename is wrong; but I don't think there's anything at user (not kernel) level that does this.
You will have to write a program to act as a gateway to the share to enforce this. You'll also have to restrict access to the share so users cannot circumvent the program.