We have an idea of creating a page which would display information about all currently loaded DLLs (name and version). Is there any risk in terms of security, i.e. can a malicious user compromise the site security knowning the dll name and version number?
Knowing .dll version numbers is not inherently a direct risk, though it is good practice to give attackers as little information about your environment as possible. Consider at least protecting your page by requiring authentication and authorization to view it.
Related
I would like to develop a new web-app in node.js (using express). I am relatively new to node.js world, so I assume there are frameworks that I am not familiar with.
Is there any framework (like Spring for Java) that manages authentication (and save the trouble from the developer)? Or each developer has to write this code over and over again?
Login/Logout is not all. There are other flows:
registration (create account),
forgot-password (and then set new password),
locking/unlocking an account,
change password
and I think I have covered all flows.
I know that each application has its own UI, forms, maybe with its logo, but the flow itself is similar for most applications.
In addition, I know that it is not that hard to implement, but it could be great to have some kind of tool / framework / infrastructure which implements the flows.
Is there such a tool/framework which helps applications' developers and implements these flows?
I've searched this issue but could not find anything.
Thanks!
Long ago I have developed authentication-flows for Java over Spring, and recently I wrote authentication-flows-js.
It is a module that answers most flows - authentication, registration, forgot-password, change password etc., and it is secured enough so applications can use it without the fear that it will be easily hacked.
It is for node.js applications (written in TypeScript) that use express. It is an open source (in GitHub). A release version is on npm, so you can use it as a dependency in your package.json.
In its README (and of course in the npm page) there are detailed explanations for everything and if something is missing - please let me know. An article will be published soon (I will add a link as a comment).
You can find here an example for a hosting application.
NOTE: I have heard comments like "It's not so difficult to implement". True.
But you have to make sure you take care of all cases. For example,
what happens if a user tries to create account that is already exists?
what happens if a user tries to create account that is already exists
but inactive? what about the policy of the password? (too long/too
short/how many capital etc.) what about sending the email with the
activation link to the user? how you create this link? should you
encrypt it? what about the controller that will receive the click on
the link and activate the account? and more...
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!).
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.
When I create an Azure ASP.NET application, by default .NET trust level is Full trust. I always change it to Windows Azure partial trust which is similar to ASP.NET's medium trust level.
You can do it either by using GUI when you select Properties on the Role or by setting enableNativeCodeExecution to false in the definition file (.csdef) just like below:
<WebRole name="ServiceRuntimeWebsite" enableNativeCodeExecution="false">
As a security conscious developer I want by default to run my application in partial trust mode that provides a higher level of security. If I need to use something like Reflection or P/Invoke, as a developer I want to make the decision to lower that trust level by myself.
I'm sure there's a reason why Microsoft decided to use Full trust as a default .NET trust level, I just fail to see it. If you know the reason, or you think you know it, please let me know.
Full trust is not only required for P/Invoke for .NET reflection as well. As a bottom line result, nearly all moderately sized apps need full trust because nearly all widespread libraries need it too (NHibernate for example). Actually, I have been asking from the exact opposite question on the Azure forums too.
The issue of full or partial trust pertains to the environment in which your application runs. The more control and/or "ownership" of the environment and assemblies you have, the more acceptable it is to have full-trust settings.
For example, if you create an Azure web site (July 2012 capability) and, mimicking wordpress or Umbraco, your web site allows arbitrary assembly plugins to be downloaded and installed, then it is important to have a partially-trusted environment. It is possible that one of the plugins downloaded and executed, which you don't control or own, contains malware. Not only does this impact the security and stability of your web site, but some may argue it impacts other (multi-tenant) hosted web-sites which have no relation to yours.
Certainly your web site will rely on 3rd party libraries, such as Log4Net or StructureMap, but those are extremely well-known and vetted libraries that are not in question regarding their security impact. Ergo, if you are running an Azure web-role (a much less "multi-tenant" type affair) and you are merely running such "trusted" 3rd party apps, then there really is not an issue with running as full-trust.
Yes, unfortunately it is still very hard (if not impossible) to write large .NET apps that run in partial trust.
We need much better technology and tools (like CAS.NET)
Because Medium Trust is now officially obsolete. If you start a new web project in Visual Studio, it already requires Full Trust (and doesn't work partial trust). Microsoft says: Do not depend on Medium Trust, instead, use Full Trust, and isolate untrusted applications in separate application pools.
Sources:
Stackoverflow answer: Quoted response ASP.NET team
Microsoft: ASP.NET Partial Trust does not guarantee application isolation
Microsoft: ASP.NET web development best practices
Is it practically possible for a malicious developer exploit your application by swapping a genuine .dll file for a modified one.
If so are there steps that can be taken to protect an app. Are there some types of functionality that should not be placed in .dlls for example?
As long a signature of the exports is known is very easy to replace a DLL.
It's also possible to reverse engineer the signature if it is not known.
To help prevent this problem you can use Code Signing, so you can verify the signature before using the DLL.
For .NET applications, you can sign the DLL. I'm not sure if something similar exists for non-.NET assemblies.
Anyone with write permissions to your application installation directory will also be able to modify your executable file, so trying to protect against DLL substitution is far from sufficient for many attack scenarios. Is there some particular scenario about which you are concerned?
You should also consider DLL injection, where by a malicious user can for example view passwords in your password fields.....
check out these links:
http://en.wikipedia.org/wiki/DLL_injection
http://www.codeproject.com/KB/DLL/DLL_Injection_tutorial.aspx