A very well known major drawback of using CGI is poor webserver performance. But how secure are CGI (mainly C/C++) based applications? Are there any major security holes in CGI architecture built on C/C++?
I would like to know some real life implementations of CGI based web apps/web sites. One that I know of is javaranch.com.
The major security hole I would see anywhere, C/C++ included, would be not using a standard, open CGI library, not reading its documentation, and thinking you're secure anyway.
don't re-invent the wheel. Use a CGI library. Some languages have this built-in (PHP probably does), others have it included (Perl comes to mind), others need you to grab it from elsewhere (C/C++). Make sure you know what it is, and that you use it. Do not try to implement it yourself. If you have to ask about security, you, like me, are not qualified to write it.
Read the documentation. If you're using a well-established library, there will be documentation on security issues and what you can do to avoid them.
Do not ever assume you're secure. I'm quite sure I'm not secure, even though I've followed all the rules in the CGI library for Perl, and the rules in the database interface library, etc. But I still assume I'm not secure, and keep it on the forefront of my mind when doing anything there. Should I ever be an expert on security, maybe I'll change my assumption. Not sure yet.
Security is always multi-faceted, and always incomplete. There are holes being found in all sorts of software all the time - software that may have been previously thought secure. And now we have many more best-practices for security than we did, say, 15 years ago. And we have SELinux for more security.
Of course, the question is - do you have enough security for your app? Does a reasonable effort get you a reasonable level of security? Of course, that's why I don't use C/C++, but I use Perl instead. It takes a lot less effort to ensure I don't overwrite memory in Perl than it does in C++. That's a level of security right there with no actual work involved.
CGI is no more insecure than any other WSAPI. It's all about what the program does with the code. All CGI does is set environment variables and handles off to the program.
Many sites are CGI based. Many PHP sites that are located on hosting are run in CGI mode - mod_php is hard to used in shared environment - no suid.
In general, running as CGI has lower performance, but better for security - you have no access to webserver internals (as with mod_perl and mod_php) so using vulnerabilities is harder. If you use cgi-bin, you non-execute files are not visible (a common bug of PHP programmers is that they have libraries with extension like .inc so source is shown when this file is requested directly).
Perl's taint-checking mode provides a marvelous way to increase security.
Related
I don't usually post in forums because normally I can find any answer I need using Google. However every search that I am running is giving me very specific results, such as buffer overflow vulnerabilities that already exist for a specific game or system which is not what I need.
I have a home network including Windows Server 2008 R2 and my son wants to start a Minecraft server which of course I want to give him full access to so he can learn. However, I know that every game is "moddable" and he uses custom maps and the like in a lot of his games.
My concern is that I am going to create security risks on my network based on inexperienced programming. Will giving him the ability to install and create mods on my server potentially open up vulnerabilities (outside of the open Minecraft ports) due to the possible inexperience of people actually writing the mods? Or do mods just simply not work that way and I can't find an answer to my question because it's retarded and no one actually programs a mod lol?
Depends on the way the mod system works for the game, and whether the game itself is sandboxed. Importantly, no software is perfectly secure. You have to decide what level of security and reliability you are happy with.
There are several ways a mod could expose a vulnerability:
The game could allow the mod access to an inappropriately permissive set of actions, such as access to the filesystem. This can include the developer not sandboxing the mod properly.
The mod could exploit a vulnerability in the game's API to access actions the game developer didn't intend. This would be due to a bug in the API.
The mod could exploit a vulnerability in the language engine (for example, Java has a long history of security vulnerabilities).
The mod itself could be vulnerable to attack, and could be made to launch one of the attacks above.
If the mod system is script or VM based, such as Lua, JavaScript or Java, I would feel relatively safe installing mods (so long as the game has a well implemented API/sandbox), because exploits 2-4 are relatively unlikely.
(My understanding of native code mods/plugins is limited, but I'm pretty sure you MUST trust a native mod if you want to run it. Even if you do, it might still be exploitable. )
My understanding of minecraft mods is that they are written in java. My feeling about the Mojang guys is that they know what they're doing, so I'd be surprised if their mod API isn't exceptionally well designed and implemented. Having said that, installing mods necessarily introduces a security risk.
If this risk is unacceptable, you can reduce it by introducing depth to the system. Why not, say, run your minecraft server in a virtual machine, with limited access to the network (only required ports, for example)? That way the impact of vulnerabilities is reduced greatly.
I'd recommend creating a Ubuntu VM on VirtualBox (because they're both free as in beer), but you could install it on whatever OS you're comfortable with.
Buffer overrun vulnerabilities are associated with programming languages that permit unchecked memory access. Minecraft is written in Java, a language which is not susceptible to buffer overruns, so a pure-Java mod would be very unlikely to exhibit anything resembling this kind of vulnerability.
Naturally programs in Java can still be vulnerable to other kinds of security issue, either against the game itself (eg there have been game-account login exploits against Minecraft servers) or against the server (I'm not aware of any known cases of this for Minecraft, but it's always possible). The usual mitigations for running servers apply, for example lock down network access to good IPs if possible, run server as limited user and so on.
As far as know, I must be careful with PHP, and I think Javascript. What else?
Security vulnerabilities are (mostly) independent of the language involved (except for memory issues).
Instead, you should focus on tasks with potential vulnerabilities, such as processing user input or handling sensitive data.
Some things to watch out for:
Always use parameters in SQL
Always escape correctly (when generating HTML, JSON, Javascript strings, or anything else)
Be extremely careful when executing code dynamically (eg, eval, automatic updates, etc)
Always validate user input on the server
You should also read articles about security, such as the Top 25 Most Dangerous Programming Errors.
OWASP provides an annual report describing the top ten web application security flaws (see link below for description of the project and the most recent report). As SLaks wrote, many vulnerabilities are independent of the language. Web applications need to be designed with security in mind.
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
I have a WSGI application running in PythonPaste. I've noticed that the default 'Server' header leaks a fair amount of information ("Server: PasteWSGIServer/0.5 Python/2.6").
My knee jerk reaction is to change it...but I'm curious what others think.
Is there any utility in the server header, or benefit in removing it? Should I feel uncomfortable about giving away information on my infrastructure?
Thanks
Well "Security through Obscurity" is never a best practice; your equipment should be able to maintain integrity against an attacker that has extensive knowledge of your setup (barring passwords, console access, etc). Can't really stop a DDOS or something similar, but you shouldn't have to worry about people finding out you OS version, etc.
Still, no need to give away information for free. Fudging the headers may discourage some attackers, and, in cases like this where you're running an application that may have a known exploit crop up, there are significant benefits in not advertising that you're running it.
I say change it. Internally, you shouldn't see much benefit in leaving it alone, and externally you have a chance of seeing benefits if you change it.
Given the requests I find in my log files (like requests for IIS-specific bugs in Apache logs, and I'm sure IIS server logs will show Apache-specific requests as well), there's many bots out there that don't care about any such header at all. I guess almost everything is brute force nowadays.
(And actually, as for example I've set up quite a few instances of Tomcat sitting behind IIS, I guess I would not take the headers into account either, if I were to try to hack my way into some server.)
And above all: when using free software I kind of find it appropriate to give the makers some credits in statistics.
Masking your version number is a very important security measure. You do not want to give the attacker any information about what software you are running. This security feature is available in the mod_security, the Open Source Web Application Firewall for Apache:
http://www.modsecurity.org/
Add this line to your mod_security configuration file:
SecServerSignature "IIS/6.0"
Looking around the horizon of the web server side, I see that scripted languages like PHP are quite popular,
probably due to the speed of development and ease of programming.
However scripted languages are human readable so isn't code security would be an issue here.
I would like to know that if I am keen of security of my code on the server what server language/technology would be most suitable.
When you use any server side language, only people with access to the FTP protocol (or SSH), can see the files. When you are regularly browsing the web, you cannot see PHP, or any other scripting language.
In terms of the actual language security, little bugs can be found, but you will get that in every language.
The security of your script depends on how you design it.
For the most part, every language is secure, but not every programmer is.
scripted languages are human readable
so isn't code security would be an
issue here.
No, users on the web will never see the code of your serverside programms - unless you publish the source.
Some security problems in web applications stem from the type of language used on the server side: buffer overflow is a security problem typical of C. So a scripting language would actually be more secure in this regard.
Typical security problems in web apps today stem from the interaction of client, server, database and user-entered data:
SQL Injection
Cross Site Scripting
Cross Site Request Forgery
...
A modern Web Framework like Ruby on Rails (or many others) will help you avoid some of these problems. But you still will have to learn a lot about web security!
"Staying away from Javascript" is a bit like "staying away from cars" because they are dangerous. Javascript is an integral part of modern web applications.
All serious (ignoring Piet, Malbolge, etc) programming languages are human-readable. Whether or not an explicit compilation step is required has no effect whatsoever on application security.
If you want to be very careful about security, use a language which supports easy verification and/or proofs, such as Haskell or Ada. A typical web application probably would be OK with a modern dynamic language, such as Python or Ruby. Java and C# are also popular, for performance reasons. Any of these will make developing secure applications significantly easier than in legacy platforms such as PHP, Perl/CGI, or classic ASP.
Lastly, as a small pet peeve -- PHP, Python, Ruby, Perl, etc, are not scripting languages.
I would say that the only really safe way to protect your code is by using ISAPI or CGI, and developing the application with some hard compiled language like C, C++, VB 5 or higher but any .NET, Delphi 5 or higher and so on. Any bytecode or interpretated language can be decompied, no matter what you do. New obfuscation methods may hold the crackers for a while, but they will always find a way to get the source. The source is there, the decompilation routine is there, the source must be revealed to be used by the framework, so all the crackers have to do is to catch it on the way.
the language has a small part to do with it. however, a lot has to do with how you actually design and write the code.
ASP.NET get compiled into dll's, so the code is not human readable on the server. But even in PHP, the code gets executed on the server.
Just stay away from JavaScript as that is visible on the client, and human readable.
My main preference is .NET, however even with the scripting languages like PHP they are not seeing your raw code unless you're giving people access to read the raw code files. I've seen some very secure PHP sites. If you're concerned about what people can see and access, then you need to watch what you are putting into the client side scripting languages like Javascript.
For 'hiding' the code there are a few different languages that support this. .NET languages can be compiled, which generates DLLs without containing the original source code on the server. These, however, can be read with something like .NET Reflector, so to escape that you would run something like Dotfuscator on your code, making it more difficult to read.
For PHP, there are solutions such as ionCube that encode your script and they must be ran with an additional decoder on the server to execute them. Usually this is used when reselling scripts, so clients can't look at or modify the source.
This question is more security related than programming related, sorry if it shouldn't be here.
I'm currently developing a web application and I'm curious as to why most websites don't mind displaying their exact server configuration in HTTP headers, like versions of Apache and PHP, with complete "mod_perl, mod_python, ..." listing and so on.
From a security point of view, I'd prefer that it would be impossible to find out if I'm running PHP on Apache, ASP.NET on IIS or even Rails on Lighttpd.
Obviously "obscurity is not security" but should I be worried at all that visitors know what version of Apache and PHP my server is running ? Is it good practice or totally unnecessary to hide this information ?
Prevailing wisdom is to remove the server ID and the version; better yet, change them to another legitimate server ID and version - that way the attacker goes off trying IIS vulnerabilities against Apache or something like that. Might as well mislead the attacker.
But honestly, there are so many other clues to go by, I wonder about whether this is worth it. I suppose it could stop attackers using a search engine to find servers with known vulnerabilities.
(Personally, I don't bother on my HTTP server, but it's written in Java and much less vulnerable to the typical kinds of attack.)
I think you usually see those headers because the systems send them by default.
I routinely remove them as they provide no real value and could, as you suggested reveal information about the server.
Hiding the information in the headers usually just slows down the lazy and ignorant villains. There are many ways to fingerprint a system.
Running nmap -O -sV against an IP will give you the OS and service versions with a fairly high degree of accuracy. The only extra info you're giving away by having your server advertise that information is which modules you have loaded.
It seems that some of the answers are missing an obvious advantage of turning off the headers.
Yes, you all are right; turning of the headers (and the statusline present e.g. at directory listings) does not stop an attacker from finding out what software you use.
However, turning this information off prevents malware which uses google to look for vulnerable systems from finding you.
tldr: Don't use it as a (or even as THE) security-measure, but as a measure to drive away unwanted traffic.
I normally turn off Apache's long header version information with ServerTokens; it adds nothing useful.
One point which nobody has picked up on, is it looks like better security to a prospective client, pen testing company etc, if you're giving out less information from your web server.
So giving less information out boosts the perceived security (i.e. it shows you have actually thought about it and done something)