I want to let my users post articles on my website but i have serious concerns about ckeditor security.
What i want to ask is:
Can users upload any kind of codes that can put my site at risk through ckeditor?
Is there any way to limit users of those kind of actions?
About my application:
I'm using laravel 5.6 and ckeditor last version.
Please share your thoughts and experiences.
CKEditor is not insecure on purpose. No sense in developing an insecure product (except for educational purposes). It doesn't allow uploading executable content (as a feature). However, it does have a history of publicly exploited vulnerabilities, mostly due to it's handling of wide variety of user input that will be stored in user accessible locations/paths.
Nonetheless, you can still mitigate it's risks substantially if you simply restrict the paths which allow web app execution (php, asp, etc...).
PHP example:
Create an .htaccess file in the dir where ckeditor places it's user generated/uploaded data. Inside that file place the following:
php_flag engine off
There are additional methods to achieve this, which depend on your specific environment. But the main idea remains - block execution abilities in the target dir for user content/uploads, and watch out for security updates for all your components.
One last note - the best practice to avoid users uploading executable content would be to store in a non-web-exposed location. I would even advise outside of the web served root dir. This also would help to prevent a big portion of path traversal vulnerabilities. But specifically for CKEditor type of plugin it makes the solution much more complicated, since that content needs to be accessed by web users (by design!).
Related
I work in a company where we have many different applications. To reduce code repetition and keep the experience for the users the same across applications we created a component library which is used by all applications.
Now we want to allow the users to switch between applications. Something similar like Google does:
Screenshot of Google Application Drawer
An additional requirement for our "Application Switcher" would be that it "updates" itself. Meaning if we change how this "Application Switcher" looks we don't want all applications which use this Switcher to create a new deployment and be newly deployed.
So currently we use the same header (from our component library) in all our applications. So, my idea was just to simply add a script tag to all the index.html pages of all the applications which should support this "Application Switcher". The Script would parse the DOM, find the header and inject a component for this application switcher. I wanted to host the actual script from a CDN like server and the script tag in the index.html just references this URL. This way we could change this script however we want, and all the applications will always get the latest version.
Now I did a small proof of concept in our environments and solved all the CORS issues but since we were fetching from an authenticated context and the script was also in an authenticated context I always got a 401.
Additionally, we have the requirement, that this "Application Switcher" shows different applications to different users i.e. depending on which apps a user is allowed to access. So, the script itself will also do calls to an "Application Switcher" backend providing it user-specific information.
Now this makes me think that my initial idea of just putting a script tag and fetching from a CDN was too simplistic. Now I'm thinking if it would be better to implement a rest endpoint in all applications to fetch this script. This way I don't have the problems of fetching a resource from an authenticated context from the user's browser and instead can handle all of this in the backend.
So long story short; I feel like a complete noob who just hacks around to get things working (or actually not working) and was wondering if any of the smart internet people out there (who might actually already have experience with this) could give me a hint what would be a clean way to implement this?
I'm new to web development, and I'm currently making a presentation website(home, services, news, vacancies) for a small company. I'm using Node.js,Express and MongoDB.
The client wants to manage certain content on the website, therefore there needs to be a dashboard, where only admins could login/register. But website design does not provide any login/registration system for users.
The question is, where do I put a dashboard and how should I hide it from ordinary users? Should I just use url, like mysite.com/admin, which should be typed by the admin, whenever he wants to get to the admin login/dashboard zone(it seems quite unsafe, since everybody on the internet could type that and get to the login form)? Or maybe I should make a separate desktop app for managing website content?
How should I approach this problem, what are the best practices?
Thanks!
You don't need to reinvent the wheel as i think you can first explore CMS systems and check if the tools covers your requirement . Since CMS tools brings in lot of website admin capabilities as out of the box features.
Following links will get you started.
https://en.wikipedia.org/wiki/Content_management_system
https://en.wikipedia.org/wiki/Web_content_management_system
Is it not secure to enable user to add his own rules of CSS to his personal page, in (for example) a social website ?
It is not secure. There are multiple ways to embed JavaScript in CSS such that it gets executed by at least some browsers. Google "XSS CSS" and look through the top hits.
Don't do this unless you're willing to do hardcore sanitization of the CSS, and to clean up the mess when your sanitization is inevitably bypassed and your users' cookies are compromised.
Allowing them to enter the CSS as free-form text (or upload a file) could lead to security problems. It might be safer to give them a Control Panel that lets them customize the look and feel (with limiations of course, it might be impossible to build a form that lets them customize EVERYthing), and implement the customization via CSS, while storing their settings as values in a structured set of database tables.
I think somebody answered this question before.
History lesson: myspace allowed custom CSS and scripts. For those of you not hanging around on the web in 2003 or so, this was a major security threat. Later on, the mass of user generated CSS which had been a selling point became a major detriment to the platform as many changes and improvements could not be made as they effectively had created a public API for their CSS hooks.
So it is a really, really bad idea to let users do CSS.
Are there any special security measures to take when deploying a Drupal site to a production server?
For instance: I can imaging that we need to remove install.php from the root directory. Are there any more actions?
Or is there maybe a module available which checks the site for "world readiness"
The status report on http://your-site/admin/reports/status will tell you if anything is not quite right.
Under the performance admin page you can turn on various caching settings, but test your site with them turned on before deploying.
There is a book by greggles for securing drupal, which may be worth a look.
Ideally you've tested your code for insecurities before deploying, but configuration can often be missed. There's a mode for analyzing your Drupal site for misconfiguration that would lead to vulnerabilities http://drupal.org/project/security_review
Security Review makes the following checks:
Safe permissions on system files
PHP in comments or nodes
Whether error reporting is on
Unsafe input formats
If private files is on and if the files directory is outside webroot
Allowed upload extensions
Admin permissions granted to untrusted users
In addition to other suggestions, remove update.php also.
I'd also (re)move /scripts from the webroot
It's a minor thing, but you could remove the text files in the root of the distribution which leak the version number. Such as CHANGELOG.txt etc.
I don't remember how safely cron.php protects itself from flood-calling. You may want to look into whether it is worth limiting that to local-only or command-line-only access.
Ensure that .inc files are processed by PHP.
all this answers make you stop thinking after your install is done - but software has a history and after installing drupal you have one more baby to watch - in drupal´s case watch VERY closely! This means you MUST subscribe to the drupal security mailing list and read all mails that are coming form there - be prepared to get many emails. It is good, that the drupal team is providing these informations fast, but it is sad that there are really too many of these mails, what might be related to drupals programming style. be prepared to get up more than once in the middle of the night to update your drupal installation because some extension developer never did understand, why input from the web must be sanitized (yes, these kind of security problems are still happening in the drupal world.)
So "hardening" means "keeping up with updates", in drupals case these come quite often. Think about this if you have many sites and want to deploy to multiple servers - automatic deploymemts will help you save a lot of time.
Here's an excellent rundown for Drupal 7: http://www.madirish.net/242.
Most of its suggestions are relevant to Drupal 6 as well.
You should also remove the Theme registry rebuilding setting.
It rebuilds your theme registry on every pageload, so it makes your site very slow.
I've got a strong background in Linux and OSX, and just left a job where I was architecting systems based on those platforms.
Now I've got a Windows Server running IIS that has a number of different websites that it hosts. Most of them are just a bunch of HTML, JS and Images, with some ASP for some customer tools. (Each website has a different set of customer tools, or they are the same tools, but with minor code changes between them.) I'm also adding a develop web server with the same code, but the 'bleeding edge' stuff.
I need an effective way of managing changes and updates to the overall codebase (henceforth referring to both the images and the html and the asp, for all the sites). When a dev (or webmaster) checks in changes, I want it to show up automatically on the developer server, but should be manually pushed out to the live server. I'd be tempted to just make the websites SVN repositories, but I'd be concerned about the overhead of having the webdeveloper having to log into the server and trigger an SVN update via commandline/tortise (and heaven forbid, manage tags).
Ideally I'd also manage IIS profile settings between the systems, but the major need is to be able to manage the process, and expose it to our ASP developer, and our webmaster, both of which are used to just FTPing up the files to the live site.
So, any recommendations on tools (beyond some SVN hacking with BAT files + teaching the webmaster how to log into the server and do updates) or workflows that would help this out? I even considered an RPM type package (or some Windows equivalent, of course) to manage the live server, but that seems like a bit too much overhead.
First you need to decide how the webmaster knows that the latest in your SCM is ready for deployment (I assume you want some level of acceptance testing after the developer has checked in).
Depending on the above answer you should be able to define the steps to get the "approved" content built and updated on the web server, then it would be a matter of scripting this.
In the end the problem is not the commands to run, but knowing /when/ to run them, and that the last checkin from developers is not necessarily going to work 100% (even without mistakes two concurrent changes, each working, could conflict).