Maybe this isn't really feasible. But basically, I've been developing a snippet-sharing website and I would like it to have a 'live demo area'.
For example, you're browsing some snippets and click the Demo button. A new window pops up which executes the web code.
I understand there are a gazillion security risks involved in doing this - XSS, tags, nasty malware/drive by downloads, pr0n, etc. etc. etc.
The community would be able to flag submissions that are blatantly naughty but obviously some would go undetected (and, in many cases, someone would have to fall victim to discover whatever nasty thing was submitted).
So I need to know:
What should I do - security wise - to make sure that users can submit code, but that nothing malicious can be run - or executed offsite, etc?
For your information my site is powered by PHP using CodeIgniter.
Jack
As Frank pointed out, if you want to maintain a high level of security use a whitelist technique. This of course comes with a price (might be too restrictive, hard to implement).
The alternative route is to develop a blacklist technique. i.e. only allow code that hasn't triggered any bells. This is easier, because you have to specify less things, but it will not catch new exploits.
There is plenty information available on the web on both techniques.
Relying on CodeIgniters security functions (XSS filtering etc.) will not get you very far as most of the snippets will not be allowed through.
Whatever you do you have to remember this:
Do not think malicious code will aim to just harm your website's visitors. It may as well aim to compromise your server via your parser/code inspector. For example, lets say Alice uploads snippet foo. Alice intentionally crafts the snippet so that your parser will flag it as malicious due to an XSS exploit. Lets say your parser also updates a database with the malicious snippet for further investigation. Alice knows this. Along with the XSS exploit Alice has injected some SQL code in the snippet, so that when you INSERT the snippet to the database it will do all sorts of bad stuff.
If you are really paranoid, you could have an isolated server which its solely responsibility would be to inspect code snippets. So in the WCS only that low-risk server would be compromised, and you would have (hopefully) enough time to fix/audit the situation.
Hope this helps.
You cannot whitelist or blacklist PHP, it just doesn't work. If you write up a list of commands that I can use, or stop me from using malicious functions, what is to stop me from writing:
$a = 'mai';
{$a .'l'}('somebody#important.com', 'You suck', 'A dodgy message sent from your server');
You cannot whitelist or blacklist PHP.
For your information my site is powered by PHP using CodeIgniter
Sorry Jack, if you think that is in the least bit relevant you're a very long way from understanding any valid answer to the question - let alone being able to distinguish the invalid ones.
Any sandbox you create which will prevent someone from attacking your machine or your customers will be so restrictive that your clients will not be able to do much more than 'print'.
You'd need to run a CLI version of suhosin on a custom chroot jail - and maintianing seperate environments for every script would be totally impractical.
C.
Assuming you are only allowing javascript code, then you should do the following -
Purchase a throw-away domain name that is not identifiable with your domain
Serve the user-entered code in an iframe that is hosted from the throw-away domain
This is essentially what iGoogle does. It prevents XSS because you are using a different domain. The only loophole I am aware of is that evil code can change the location of the webpage.
If you intend to share snippets of server side code, then it is a different ballgame. For java/jsp snippets, you could use JVMs internal Security classes to run the code in a sandbox. You should find a lot of information on this if you google. I would like to think this is what google uses in App Engine (I am not sure though).
Anything other than Java, I am not sure how to protect. Dot Net perhaps has a similar concept, but I doubt you could sandbox PHP code snippets in a similar manner.
Related
As most programmers I try to program my applications in the safest way possible but this we know that does not guarantee security at 100%. Therefore I think it is also appropriate to have methods to monitor if we may be being attacked. So this is my question.
(My websites are made with PHP and MySQL)
In the case of SQL injection I think this can be done in two ways, but if there are other ways I would also like to know them.
Parsing access/error logs. Does anyone have or know a script that adequately analyzes the access logs (apache) to detect possible attacks? And notify to the administrator automatically with all details.
Analyze HTTP params at real time. It would be a script that analyzes in real time the content passed by GET / POSt and notify (e.g. via email) to the administrator of the website
For example, I do not know much about SQLi attacks but I think it's common for the 'SELECT', 'UINON',...(Others?) strings to appear in query strings and params.
In this way we can analyze the attack and see if it succeeds or not, and then take the consequent actions.
Thanks for your attention!
Edited: Simple bash script
I have made a simple system for analyzing the Apache access_log files and communicate results by email. Which is detailed in this question:
Linux bash to iterate over apache access_log files and send mail
In addition, another one using AWK. The only one resource I've found related about that:
https://www.unix.com/shell-programming-and-scripting/248420-sql-injection-detection.html
(But I have not been able to make it runs in my case)
Oh boy.
Alright, where to start?
For starters, remember that bad hackers are usually financially motivated. You know your website has been injected if you wake up one morning to a red error message from Chrome or Firefox, and you open it anyway to find that your website is now among the more popular places to find free cruises and viagra online.
Sites that score well with SEO are more likely to be hacked than sites that do not. More users means more exposure. Password protected sites don't get hacked as often, but the password protection itself does not necessarily mean any added security. If you're vulnerable, you're vulnerable, and you need to be on top of it.
First and foremost, remember to filter your variables. Never trust anything that comes in from a browser. IT'S ALL SUSPECT. That's means filtering anything that counts as a super global, GET POST, REQUEST, etc. I wouldn't even trust sessions, honestly. Filter it all. More on this can be found here: http://php.net/manual/en/function.filter-var.php
Something else to think about is file uploading. Bad guys love uploading files, and taking over your server. Most common method is exploit files disguised as images. You're going to want to resample every image that comes in. GD Works, but I like Imagick better, personally, more options. More on that here: http://php.net/manual/en/book.imagick.php You're also going to want to make sure that your site can't upload images or any other type of file from pages that you don't explicitly designate as form or upload pages. You would be shocked how often I see sites that can upload from the index, it's insane.
Another method you can deploy for this, is use your php ini to set a global include, and open up any file in a $_FILES array that comes in. Open up the first million spaces in the file, and scan it for php reserved words, and unix shell scripting. If you find one, kill the upload, exit or die, whatever you like to do there.
Apache has a setting for forensic logs. Forensic logs will capture all GET and POST stuff, but the issue with it, and the reason it's not exposed by default is that your log get big, and quickly. You can read up on it here: https://httpd.apache.org/docs/2.4/mod/mod_log_forensic.html
Lastly, you're going to want to evaluate your site for injection vulnerabilities and cross site scripting. Cross site scripting isn't the issue it once was, given the way browsers are constructed these days. All those little details that make life harder for us as a developers actually make us more secure.
But you do want to check for SQL vulnerabilities, especially if you're writing code from scratch. There are a couple reasonably solid plugins for Chrome that make pen testing a little easier.
Hackbar: https://chrome.google.com/webstore/detail/hackbar/ejljggkpbkchhfcplgpaegmbfhenekdc?utm_source=chrome-ntp-icon
HackTab:
https://chrome.google.com/webstore/detail/hack-tab-web-security-tes/nipgnhajbnocidffkedmkbclbihbalag?utm_source=chrome-ntp-icon
For Firefox, there's scrippy
https://addons.mozilla.org/en-US/firefox/addon/scrippy/?src=search
Hope that helps.
Good luck.
Therefore I think it is also appropriate to have methods to monitor if we may be being attacked.
The biggest waste of time ever.
ANY site gets "attacked" 100% of time. There are freely avalable scripts that allow any stupid schoolboy to scan whole internet, probing sites just by chance. You'll grow bored the very next day after scouring these logs of your detection system.
In your place I would invest in the protection. Other vectors than you could think of. For examle, all recent breakings I was a vitness of were performed by means of stealing ftp passwords stored on the webmaster's PC. And I can assure you that there are much more attack vectors than a blunt SQL injection. Which is a simplest thing to protect from, with only two simple rules to follow:
Any variable data literal (i.e. a string or a number) should be substituted with a parameter, whereas actual value should be sent to the query separately, through bind/execute process.
All other query parts that happen to be added through a variable, should be explicitly filtered through a hardcoded list of allowed values.
I am looking for some advice - I hope someone can help
My php site got hacked and I just found this code 'Script Encoded by Devil-Shell':
eval(gzinflate(base64_decode($encoded)))
And all these random letters/numbers...
I have a few questions:
What will happen if I delete this code? Will it have a knock on effect?
Is my site ruined?
Is there anything that can be done?
Thanks for your help.
It pretty much looks like a backdoor - I'd suggest to comment this out.
As long as $encoded is a variable that can be set externally (through HTTP GET or POST for example), anyone can execute any code on your server.
Unzip it to see what it does. Ensure it cannot be executed. Understand the damage it has done
Find your flaw in security
If that is PHP code, that is pretty serious, as they were able to append to a PHP file or to add their PHP malicious file. They basically own the server. Apart from general advices (fix your security, that can be a year of work :)) some real-life tips:
Don't erase logs, application logs or web server or db logs; keep them, it is very unlikely someone injected anything bad (apart from strings) there. Collect and keep all the logs, trust me they will be useful in the future if something bad happens.
They could have compromised the whole server with an attack like that. You need to be careful with your hosting company: they could consider you responsible for data breaches in other people's data, config, etc... It depends on their configuration and the agreement you signed with them.
Do not consider anything safe: the DB could be compromised as well, all keys and passwords and passphrases and sessionIDs you have stored since now are insecure and are in the hands of them now. So replace them ALL, as their aim could be not you but your user, and they are totally in control of their browsers too now (if they want).
You can comment that out, it seems safe enough; but they will add it again, in more subtle forms. Consider that.
Check (if you can) the traffic FROM your website. Usually they build simple webshells like that to be part of a bigger botnet. Usually they are used for Distribuited Denial of Service (DDOS), bitcoin mining or traffic exchange. So you could be considered legally responsible for such attacks/illegal behaviours as they are connected to your account and it is yours the contract for hosting.
In the internet this topic is called 'Intrustion Response' or 'Attack Response'. It is usually tailored only for big enterprises so I doubt you can find anything useful, but at least for theoretical topics it may help to google for it http://www.certiguide.com/secplus/cg_sp_SixStepIncidentResponseProcess.htm
I am using PHP to write my server side code for my website. What is the best way to prevent someone from scraping my data?
Like in PHP if someone uses file_get_contents() or someone fetches my login form in an iframe element or the data entered in the login form -
how can I prevent such things?
I am using PHP 5.47, MySQL, HTML and CSS.
I think that being a web-developer these days is terrifying and that maybe there is a temptation to go into "overkill" when it comes to web security. As the other answers have mentioned, it is impossible to stop automated scraping and it shouldn't worry you if you follow these guidelines:
It is great that you are considering website security. Never change.
Never send anything from the server you don't want the user to see. If the user is not authorised to see it, don't send it. Don't "hide" important bits and pieces in jQuery.data() or data-attributes. Don't squirrel things away in obfuscated JavaScript. Don't use techniques to hide data on the page until the user logs in, etc, etc.
Everything - everything - is visible if it leaves the server.
If you have content you want to protect from "content farm" scraping use email verified user registration (including some form of GOOD reCaptcha to confound - most of - the bots).
Protect your server!!! As best you can, make sure you don't leave any common exploits. Read this -> http://owasp.org/index.php/Category:How_To <- Yes. All of it ;)
Prevent direct access to your files. The more traditional approach is defined('_SOMECONSTANT') or die('No peeking, hacker!'); at the top of your PHP document. If the file is not accessed through the proper channels, nothing important will be sent from the server.
You can also meddle with your .htaccess or go large and in charge.
Are you perhaps worried about cross site scripting (XSS)?
If you are worried about data being intercepted when the user enters login information, you can implement double verification (like Facebook) or use SSL
It really all boils down to what your site will do. If it is a run of the mill site, cover the basics in the bullet points and hope for the best ;) If it is something sensitive like a banking site... well... don't do a banking site just yet :P
Just as an aside: I never touch credit card numbers and such. Any website I develop will politely API on to a company with insurance and fleets of staff dedicated to security (not just little old me and my shattered nerves).
No there is no way to make this sure. You can implement some Javascript functions which try to prevent this, but if the client just deactivate JS (or a server just ignores it), you can't prevent this.
It is really hard to prevent this. I have found a similar discussion here. This will answer most of your queries but if you want even more perfect protection then sophisticated programs and services like Scrapesentry and Distil would be needed.
Using JavaScript or php, you just decrease the data scraping, but you can't stop the data scraping.
Browser can read the html data so user can view your page source and get that. You can disable key events but can't stop the scraping.
I admit the title is mostly a catch 22, but it's entirely relevant, so please bear with me for a while...
Background
As some may know, I'm working on a PHP framework whose major selling point is that of bridging functionality between different CMSes/systems.
From a developer perspective, there's an extensive error handling and logging mechanism.
Right now, there are two settings, DEBUG_MODE and DEBUG_VERBOSE, which control debug output.
The mode describes the medium and verbose controls the amount of detail.
To make it short, there's a mode called "console" which basically dumps debug info into the javascript console (which is now available in a major web browser near you).
The Issue
This [debug system] works great for development servers, but you absolutely cannot use it on a production one since debug details (which include DB credentials etc) get published publicly. And in all honesty, who ever migrated from a dev. to a prod. server flawlessly each time?
Solutions
Therefore, I've been trying to figure out a way to fix this. Among my proposed solutions are:
Having a setting which tells the framework to enable logging only if the request comes from a certain IP. The security issues for this are quite obvious (IP spoofing among others).
Having a setting which contains PHP expression(code) that gets eval'd and it's return used as a yes/no. The best part is that the framework installed may suggest CMS-specific expressions, eg:
Wordpress: current_user_can('manage_options')
Joomla: $user=&JFactory::getUser() && ($user->usertype=='Super Administrator') || ($user->usertype=='Administrator')
Custom: $_SERVER['REMOTE_ADDR']=='123.124.125.126'
These are among the two, I'm eager to hear out more suggestions.
So, do you think eval() should be up to it? I'll ensure it still performs well by only doing this once per page load/request.
Clarification
if(DEBUG_MODE!='none')echo 'Debug'; // this is how it is now
if(DEBUG_MODE!='none' && $USER_CONDITION)echo 'Debug'; // this is how it should be
The $USER_CONDITON allows stuff such as running is_admin() to allow all admins to see debug info, or, getUser()->id==45 to enable it for a specific user. Or by IP, or whatever.
Go ahead. It's evident that you understand the hypothetical security implications. In your case it's just important to tell the target user base about it.
As for the practicability of your approach, there's no discussion really. You need variable authentication logic and can't hardwire it to one specific environment/cms runtime.
The only concern you see is about performance. That's baloney. Not an issue. The presence of eval is what discerns scripting languages from compiled languages. If it's available you can not only use it, but can be sure that it's not going to be slow because a compiler+linker run is required behind the scenes. PHP takes some time with initializing its tokenizer and parser, but parsing itself is surprisingly quick.
And lastly, avoid such question titles on SO. ;} Or at the very least talk about create_function please.
IP spoofing long enough to actually get a response is unlikely to occur. If a user manages to build up a connection to your server, spoofing an internal or privileged developer IP they control your router, so you've got other things to worry about.
Rather than running eval can't you just write an anonymous function/closure: http://php.net/manual/en/functions.anonymous.php
(putting it in a config file, rather than web screen, writing complicated PHP code on a web form seems sub-optimal anyways)
Allowing free-form input of PHP code that gets executed - be it through eval() or create_function() - is simply bad design, and opens a big potential vulnerability for no good reason. It also opens the possibility of crashing a page through syntax errors.
Even the argument that the administrator can install plugins anyway doesn't hold entirely, because XSRF attacks are conceivable that manage to get malicious stuff into a text field (one request), but can't trigger a plug-in installation.
So no, I wouldn't do it; I would implement each CMS bridge as an adapter instead, and let the user choose the adapter (and if necessary enter some custom, sanitizable settings) from a pre-defined list. (Something similar was also suggested by #Wrikken in the comments)
It's your call. Chances are you will never have a problem from doing this the eval() way. And it can be argued that most of the CMSs you will be connecting with (Wordpress, Joomla) allow arbitrary execution of PHP code in the back-end anyway. But it's not good design.
Having a setting which contains PHP expression(code) that gets eval'd and it's return used as a yes/no. The best part is that the framework installed may suggest CMS-specific expressions, eg:
eval() may crash your page if any function doesn't exist or on any number of parse errors. And if bugs exist which allow user-supplied input (such as a uri requested) to even touch these evaled values, it will potentially open up your site to malicious or accidental destruction. Instead to identify the currently working framework, look for markers in the framework you're trying to bridge to, such as certain constants, functions, classes, etc. You can replace all your eval() functions with safe checks using function_exists(), defined(), etc.
I'm looking for an automated way to fuzz my app or scan it for vulnerabilities. Please assume that my hacking knowledge is 0. Also the source is on my localhost so I need a way to fuzz it locally without relying on an internet connection. Can some security experts give me some hints or recommendations? I'm not sure what options are best.
Edit:
Thanks for the effort to answer, but none so far seems to get the point. I'd like to be more specific (because it helps the question) but without influencing opinions or sounding like I'm advertising a specific product. I'm looking for something like wapiti (sorry to mention names, but had to, because answers so far like learn about sql injections, xss etc. are obviously not real "expert" answers to this question. I already know about these (seriously, does this question sound like it could asked by someone who doesn't know salt about security?)
I'm not asking whether I should test, I'm asking how I should test. I already decided to incorporate automation (and there's no turning back in this decision unless someone gives me an expert answer that proves it useless), so please respect my decision that I'd like to automate. I don't want to go through every compiled xss, sql injection, etc. hack list and try it manually myself against my site (even hackers don't hack that way). Super extra points to anyone who gets the question.
Some people are asking why not just learn.
Best practices (which I know) are not the same as knowing hacking. Some people want to argue they're a flip-coin, but I definitely don't agree :) hence I need a protection tool by someone with the "hacker mentality". How is that going to hurt, in fact, you should try it too ;) Expert answers please from those who know.
There are services that will do automated scans for vulnerabilities. They will not catch everything, but will help you identify problems. Your best bet is to use one of these services and LEARN SOME SECURITY best practices.
Start learning about sql injection and cross site scripting. these are the biggest and easiest to fix vulnerabilities.
Programming defensively is a skill that IMHO every programmer should learn.
There is no substitute for understanding these issues on your own.
To strictly answer your question the way you should test is by using a tool. There are 2 main types of tools you can use, a security scanner which actively probes a running website or a static analysis tool which runs on the source code you use to build your webapp.
The short answer is you want a security scanning tool like wapiti or burp. Tools like these dynamically construct and execute security tests uniquely for your site. You could manually attempt to exploit your own site but that would take lots of time and not provide any value. It would be useless for you to go through a list of known xss or sql injection issues because each issue is unique to the site it applies to. Furthermore these tools can attack your site better then you can giving you a more rigorous security stress test.
There are 2 main tools you can use, static analysis tools and dynamic analysis tools. Static analysis tools read in your source code, figure out the way the data flows through the app and look for security issues. At their root most security issues are allowing a user to control some data that flows into an inappropriate part of an application so even though the app isn't running and you rub up against the halting problem, static analysis method of "guessing" and trying out each code path can yield good results. Static analysis tools are language dependent and most are expensive. Some free ones are fxcop (C#), PMD and findbugs (java), see http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Dynamic analysis tools (more commonly just called "security scanner") require you setup your webapp so it can run tests against it, this sounds like more what you want. My favorite tool here is burp, some free ones include wapiti which is good as well. These tools will look at how your app handles data, look for inputs and fill them with malicious data in an attempt to trigger vulnerabilities. An example test would be for testing reflected cross-site scripting, the scanner would look at a page and insert javascript into every querystring value, cookie value, form value etc and then render the page to see if the malicious javascript was echod back to the page.
You likely don't need or want a fuzzer. Fuzzing tools mostly help you when there is a lot of parsing code so a fuzzer is not the best fit for a webapp whereas it would be a good fit for a protocol you are making. There is limited fuzzing capabilities in the security scanner tools listed above and you probably don't need more then this. Fuzzers also take time to build. Fuzzers often find more stuff in c/c++ code because there are less libraries built in already doing the right thing, in the webapp case there is less "room for fuzzers to play" so to speak.
Before you go crazy on automation (which will likely yield results you probably won't understand), I'd suggest that you read up of writing secure code instead and learn to identify the things you are doing wrong. Here are some tutorials to get you started:
http://php.net/manual/en/security.php
Failing that, I'd suggest outsourcing your code to a security firm if you can afford it.
Good luck!
Provided you know C, You can work with spike, Its always good to do a manual check for overflows in anything that could conceivably be touched by an end-user, The usual %x%x%x tests for format string attacks, and just to be diligent in your static analysis.
PeachFuzz and SPIKE are both well documented.
Failing that, writing your own is trivial.
Knowing what fuzzing is and how you may want to approach does not necessarily lead to the skills necessary to thoroughly test and evaluate your software for vulnerabilities and flaws. You need to use automated testing, but in a tuned manner where you modify the testing that the tool is doing as you find new input paths, interactions, and so on.
Basically, what I'm saying is that you need to know what you are doing if you want this to be a real value add. You cannot just pick a tool, run it, and expect to get good results. You need someone who does this type of testing to work either with or for you. Tools are useful, but can only produce useful results when used by someone skilled in this art.
I've used Paros - http://www.parosproxy.org/ - its free, easy to use and displays both the cause of the error, the possible fix and how to replicate it (usually a link).
It easy to configure and spiders your entire site - it can also spider local installations.
It has a gui as well.
Its old, but its good and easy.
I tried to configure WAPITI but it was simply too hard for me.
I've been researching this topic for many years for my own application and found a fantastic tool recently which was based on PAROS (see my other answer above)
Its ZAP from OWASP and is the ducks nuts.
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
One of the best things you can do is integrate ZAP into your project automation / build so whenever you do a build the test runs.
Even better, you can sit it next to your selenium automated tests to 'collect' the pages you test, then......scan the hell out of them!
Its really well documented, but you'll need a fast PC as it runs hundreds of tests per page. If you're doing a whole site it can take some time.
There are some other tools you might want to consider
http://sqlmap.org/
I found this tool....scarily easy to use and very very comprehensive.
Whenever I got what I thought was a 'false positive' with ZAP, I'd scan the page with SQLmap (you gotta figure out how to use Python - its easy, took a couple of hours) and SQLmap would either verify the false positive or find the vulnerability.