Security Archives - PHP Advisory

Developing Secure Web Applications

Introduction Security is definately not an add-on. Security is something that must be concieved and nurtured from the early points of your design. Using SSL and other technologies is noble and useful, but security needs to be a notion that is applied to the very design of your applications. If the roots of your application are not secure, all the technologies you add to it will usually be in vain. As we make this journey, let us remember that total security is illusion. Those advertisments that Oracle makes about their products being unbreakable are foolish. Any seasoned expert in the field of security will laugh at that. Everything is insecure, its simply a matter of how insecure it is. To reduce our risks we should aim at making our products LESS insecure. Any product that says it is unbreakable or unexploitable is not telling the truth about its security. There are many things to worry about. Buggy and blatently insecure software can allow outsiders to potentially do many different things: – execute arbitrary commands on you system – view confidential information – delete important data – dupe your system into thinking they are someone else – gain information about your system and other systems on your network – launch attacks on other servers – intercept data being sent to and from your network As a result of the great risk, it is important that we take a systematic approach to application development that is relatively secure. Four-Layered Web Security When trying to secure a web application, there are four primary layers that we should be concerned with. They are as follows: – OS/Web Server Layer – General Application Layer – Specific Application Layer – Data Layer In case that list isn’t self explanitory, I will go over it quickly. The OS/Web Server layer involves the setup of the operating system and web server. In most cases this involves Linux and Apache. Ideally, this would not be the concern of a developer–but rather a system administrator. This is the first and most crucial step to writing secure web application. The most secure application can be comprimized easily if the server it is running on is insecure. As we move past the first layer, we must move on to the General Application Layer. This layer involves general issues that are in common for just about any web application. The General Application layer involves stuff like GET and POST queries, writing to files, session, etc. This layer includes things that you would deal with in nearly every web application you do. The next thing you should worry about is the Specific Application layer. This layer involves issues that can’t be globally applied to every application you make (ie. WDDX or credit-card transactions). The last layer is the data layer. This is something that a database administrator will probably worry about if you are dealing with large scale implementations. Dividing web security four layers is helpful. Think about these layers and how you can improve the security of each layer. I recommend you stick with the first layer until your are confident with it, then move on to the rest of the layers. It may be a good idea to develop your libraries and classes with second layer security in mind because they will probably be reused alot. The third layer will probably be significantly different in each application, so there is no real way to re-use it in most cases, but there are exception. Disposing of False Untrue Disinformation There are many misconceptions that tend to be generally accepted. Lets expose them! Obscurity does not equal security. hiding your source code is a nice try, but it doesn’t make things more secure. For a vivid example of this, check out the security exploits that have hampered IIS. If the security of your applications relies on its source being hid from prying eyes, your application is not secure. Write your code so that if the whole world would see your source and it would still take them much effort to hack it. Security is not something that can be an add-on. If security was an add-on, everyone who had certain add-ons would have secure applications. That is not the case. You can throw SSL,digital signatures, PGP, and just about any other technology to your system and still have a relatively insecure system. Use technologies to help you to get to your goal of having better security, but don’t think of them as your one-way ticket to perfect security. You may limit access by IP address, but that is not necessarily very secure. What if someone exploits the site which you limit access from? There is also many ways to spoof IP addresses. Following a set of rules will not guarantee your application will be secure. There is no set of standards or rules to follow to ensure that your application are secure. The best you can do is follow a set of PROVEN principles and be ready to adapt to any changes that might be necessary to improve security. Nevertheless,that is not a silver bullet. General Security Principles to Apply There are a set of principles that you can apply to your development activities that will empower you greatly in your ability to write secure applications. Check them out! Control who accesses your web services. Minimalize who knows about about them. If your web application is for internal use only, there is no reason it should be accessible from the outside world. Do less and check/test more. Write minimal applications. Don’t get fancy until you can handle the added complexity. Integrate your changes incrementally and be cautious of what changes you are making to your source. One “fix” can often open upon many other holes. Perform rigorous testing and validation. Use phpUnit (unit testing package) if you are developing a fairly large and complex application or library. Be careful what you borrow. Everybody (even managers) stress the importance of not “rebuilding the wheel”.

Developing Secure Web Applications Read More »

Password Security and Storage

Security / Zaheer

Introduction How secure IS secure enough? There’s no such thing. Period. Even the most secure systems created by the top experts can have a weak point. Despite the fact that passwords need to be treated seriously, many programmers have habits they are stuck with, or they fall into many misconceptions. There are 4 main places where password security needs to be addressed: what the user can type in, when the password is sent to the server, what your program does with it, and how it is stored. User Related Issues More users than you would guess have a tendency to type in very short passwords, passwords that are in a row or pattern on the keyboard, their own names, or an easy to remember word. Many users use the same password everywhere they go. These days there are just so many to remember, it’s close to impossible. Many users who have a lot of passwords to manage will write them down somewhere. You can’t stop them from writing it down… but you can restrict what they can choose. A good idea is to put a minimum length of 6 or 8 characters. A better idea is to also require letters and numbers. An even better idea for password security (although your users will hate you) is to provide randomly generated passwords. Regardless of how tough you want to get… at LEAST make sure they can’t choose ‘asdf’ as their password. A related issue is the use of a ‘remember my password’ feature. Is this REALLY necessary? Many users forget to log out when at public terminals. I have seen sites (like a popular online bookstore) where the ‘log out’ feature was so hidden that I had to email them to ask how to log out. Make sure that your users can easily log out and that they receive confirmation that they truly are logged out. Transferring The Password To use a secure connection or not to. That is the question. How sensitive is your information? Is it worth it for someone to try to grab the password on it’s way to the server? If so, you might want to consider getting an SSL cert. to protect the information between browser and server. Consider what someone will achieve or gain if they get someone’s password: a forum login or personal banking information? A related issue is the use of a ‘remember my password’ feature. Is this REALLY necessary? Many users forget to log out when at public terminals. I have seen sites (like a popular online bookstore) where the ‘log out’ feature was so hidden that I had to email them to ask how to log out. Make sure that your users can easily log out and that they receive confirmation that they truly are logged out. Handling The Password Once you have the password in your script’s greedy little hands, what do you do with it? Many, many, many developers think that once it’s on the server- it’s safe. Wrong. The number of worms and viruses that have been sneaking their way onto servers is proof enough that storing passwords as plain text is bad, bad, bad. But people still do it. Websites hosted on shared servers are at risk from malicious users. I cringe every time I do a select statement on a ‘users’ table and see plain text passwords. Just don’t do it. A great way to show a developer’s inexperience is by making this mistake. It’s considered sloppy- especially since better ways are so simple. At the bare minimum, create a simple one-way hash (for example md5, or SHA-1) of the password and store that. PHP has built in functions for this. It’s quick and easy. For people more serious about security, or people who are just more paranoid. Hash it twice. Or append a ‘secret’ string to it and hash that. Or combine the username and password in some way then hash and store the result. The longer you make the string to be hashed the better- just don’t go crazy and append an ebook to it or you’ll get speed issues. I’ve seen passwords that were ‘secured’ by XORing them, or ones that were reversed then stored. Gee, I wonder what ‘drowssap’ is? Don’t make up your own securing algorithm. There are optimized ones already in existence that have proven their worth. Feel free to exercise your creativity before hashing them however. Just remember you’ll have to do this each time you validate someone’s login information. Hashing should be combined with the requirement that users choose hard to guess passwords. I’ve already learned to recognize the md5 of the word ‘test’. Shorter passwords can sometimes be vulnerable to brute force attacks, so make sure they are at the very least 6 characters long. Storing The Password Try very hard to resist the idea of storing passwords in a file called passwords.txt. Just don’t do it. I know you’re rolling your eyes, but it happens all the time. It’s just so easy to find and view. Don’t call it pass.txt, users.txt, logins.txt or any similar variation. If you HAVE to store it in a file then be as obscure as possible. Don’t keep the file in the web root. And if possible, store it as PHP or some other format so that if someone finds it, it’ll look like a blank file. Better yet, use a database. Storing login information in a properly set up and secured database is your best option. It provides an added level of security, and can grow as your application grows. Woops- need to add a signup date column? Easy as pie. Try to fight the urge to name the table users or passwords or logins or something similar- it never hurts to be a little paranoid. How Does This Relate To PHP? This information about passwords can be applied generally to any programming project in almost any language. So why PHP specifically? Many new or inexperienced PHP programmers are

Password Security and Storage Read More »

WoltLab Burning Board Hijacking

Scripts, Security / Zaheer

An authentication vulnerability was reported in the WoltLab Burning Board web forum software. A remote user may be able to hijack a newly registered user account. It is reported that WoltLab Burning Board (wBB) uses predictable or guessable temporary passwords when it creates a new user account. If another user has requested a new account but has not yet activated the registration, the user’s account may be hijacked. To determine how many users exist on the forum, a remote user can register for a new account. The remote user will receive a confirmation e-mail that contains the following type of URL to activate the account: http://forum.dom/forum/action.php?action=activation&userid=345&code=1563109322 In the above example, it is shown that any subsequent user will be assigned userid of 346 or higher. So, a remote user can attempt to guess the ‘code’ for any subsequent user. According to the report, the wBB software uses the date to seed a function that will generate only a limited number of codes (possibly 30 integer words). So, a remote user can feasibly conduct a brute force guessing attack to guess the proper code for a newly assigned user account. A demonstration exploit that will apparently generate all of the possible codes is provided: for($i=0; $i<60; $i++) { mt_srand($i); echo mt_rand().”<BR>”; } Solution: No solution was available at the time of this entry. More to read: Password Security and Storage

WoltLab Burning Board Hijacking Read More »