Security GuRu

I 'm targeting the Hobbyists and Junior Developers here, not the software houses that have Design Guru's, Development managers leading teams of experienced developers.

Part 1 doesn't mean that I 'll post Part 2 tomorrow , but means that there will always be much much more enhancements and best practices so long as developers are still there on the globe .

The stuff I mention here is not mandatory. You can go and code the way you like. But these best practices will make you work much more efficiently, to make professionally looking applications with much higher quality like the big software houses and professional developers do.

You may not use all the recommendations in each application you write. Just choose what suits the application you are writing.

The numbers are for numbering. They don't mean an order. I may rewrite these items again in a different order, so just read it the way you like.

Rule no.1

I forgot, they aren't rules

So

 . Best Practice no. 1: Reusable Code

You will never be a smart guy if you spend ten days to write code that does a simple action that somebody else did. And, I guess you will be stupid if are spending that time to ReWRITE code that you have written a similar one before

Make sure you rely on Reusable Code.

What I mean here is always have your functions / methods in a reusable form that you can further use in another project. Reuse code written by somebody else in your team...

Rely on source code if it is available, frameworks, like .Net, MFC ...etc

Some big companies even sell their engines for others to use

Just make sure you aren't violating a copyright when you use somebody else's code

. Best Practice no. 2: Test Test Test and Test

Relying on reusable code saves a lot of time, because this code has been tested enough before.

But, when you write your reusable code, make sure you test it enough, so that you don't bother ReTesting it when it is reused in a new project.

. Best Practice no. 3: Distribution

Distribute your Reusable code in class files that can be used later.

Also, when you are writing your new project, distribute it to classes that have related stuff. This is better in debugging and also enhances the performance of your program.

Suppose I have 1000 methods in my applications. Imagine loading a file that has the 1000 methods. A very big load on the memory. But if it is distributed on different files what you only load what you need, when you need it, this will have a boost on your application performance.

. Best Practice no. 4: Avoid Public stuff

The user's System memory is expensive. So, don't use the Public declaration when you don't need it.

. Best Practice no. 5: Comments

Comments don't increase the file size the way you may think. It is something negligible. Comments have no effect on the performance.

So, when you write your reusable code or even non - reusable, make sure you comment on classes and methods. So that you can remember what was that method / class supposed to do when you come to use it again. This will also help other people in your company / team using your code, to understand what you did at a glance instead of revising your code line by line.

. Best Practice no. 6: Be Simple

Don't act like a rocket scientist when you code. The simple and smaller your code is the better it is. Perfection is Simple.

Again I say: Be simple. Perfection in simplicity

. Best Practice no. 7: Use Versioning

Versioning is important when you update or add new features to your reusable classes.

Don't just overwrite the old stuff. Keep the old files and make new ones with a new version number, and write a little comment to show how this class differs from the older version.

This will have lots of benefits later if you begin to face compatibility issues. It will be easier to detect the problems when you use class versioning.

. Best Practice no. 8: No Hardcoding

Don’t' hardcode the filenames, IP address numbers, FQDN machine names and credentials. Make your best to read them form files so that they can be easily changed according to the project and the deployment machines

. Best Practice no. 9: Bug Handling

If you don't have bugs then you aren't a developer

But, no need to have your program crash when the user uses it if something unexpected happens.

Exception handling in your code is very important. Try to handle the expected exceptions, with the suitable action, or a neat error message and an option to close the program. Don't wait for the crash.

. Best Practice no. 10: Logging

Make sure your program is logging the actions, time, machine name, the user account doing the action ...etc according to the sensitivity of your program , actions and clients your are targeting.

Also, have some sense. Don’t overload the processor logging useless data for non sensitive scenarios.

Either using text log files, xml files, Event logs or even Sql database, all depends on the size of the expected log or for how long it is expected to be kept.

. Best Practice no. 11: Temp

If you are acting on something that may cause a critical loss of data, make sure you make a temporary copy, so that you still have a rollback action that gets that temp back if something foolish happens and so, no data is lost.

. Best Practice no. 12: Stick to Coding Standards and Naming Conventions

This will decrease your typing errors. And will have a great value when you work in a team

. Best Practice no. 13: Avoid duplicate names

If I 'm writing a C++ or a C# application,

MyMethod() and mymethod() are 2 different ones. But in Visual Basic they are the same.

Suppose you made a library in C#.net and you had to use it later to in a VB.net application so as to make the best use of the Common Language and Intermediate Language in .Net. You will have a bunch of bugs!!

So, it is a best practice to avoid duplicate names with different casing.

Another scenario will be even if my entire project is in a case sensitive language:

Avoid the unexpected errors you may have even by the typing mistakes, which popup by the compiler, but will only give an unexpected result.

. Best Practice no. 14: Design first then code

I 'm not talking about Agile or Waterfall here. I 'm talking about the developers who begin to write on their project without having a design.

I 'm talking about the developers who begin to write a complicated class with lots of methods that rely on each others and other classes without having a flowchart for what they are going to do.

So, PLEASE: Have a clear design before writing your first line of code.

. Best Practice no. 15: Be organized, have your own library

As I  said before about reusable code. Be organized. Make your own folders having the classes you wrote before in an organized manner. Don’t just throw code files everywhere on your computer. Also, make special folders for the icons. Reusable forms that you commonly use (like the formsplash or the about form).

But, make sure you don't have your company’s property for your private library. Also make sure you check with your legal department if you are allowed to use the code YOU WROTE for your company to use it somewhere else

Security Related best practices:

. Best Practice no. 1: Code in Low Privilege

. In a business like environment, admins deploy the application, either manually or using a group policy, or automated installs ..etc

But for security reasons, the users aren't admins on their machines.

Some software doing some critical stuff like editing on registry or so , can be denied by the system , as the user doesn't have enough privileges to run it, and the admins then have to escalade the user privileges, or in some very restricted environments, your project may be even rejected and denied access.  This is especially if you are writing windows based applications. Similar stuff sometimes happens in web applications when they have complicated scripts that may look malicious sometimes. Similar stuff too happens when you write applications for Microsoft Office that have Macros. These macros may be even denied by your antivirus software.

This happens because developers are Administrators on their machines.

So, it is better to begin writing your project using an account with the similar privileges and environment like your expected user. This will make you overcome lots of problem at the coding phase.

. Best Practice no. 2: Encrypt the web.config file

The web.config file has lots of sensitive information for your web project. Just make it encrypted. Don't leave it in the plain text form.

. Best Practice no. 3: Encryption and Logging

Log files and Temporary files are the first to attack. Developers don't bother them selves to encrypt their application’s temp and logs.

Make sure you encrypt them if they have sensitive information. Also make sure you handle the security issues for who is allowed to view the logs.

Sniffing on a network is one of the everyday tasks you need so as to monitor some of the critical stuff on your network. The attackers also sniff on your network to see the traffic or alter it, which is a big compromise to your security.

First, I want to clarify some confusion between a Hub Based and a Switch Based network

Suppose I have these three machines:

Victim 1 :

Port: 1

IP: 10.0.0.1

MAC : 00-00-00-00-00-01

Victim 2:

Port: 2

IP: 10.0.0.2

MAC : 00-00-00-00-00-02

Attacker :

Port: 10

IP: 10.0.0.10

MAC : 00-00-00-00-00-10

In a hub based network (I guess you can’t find any these days):

The hub, some how, has a huge collision.

The drawback on the hub was the shared bandwidth and the big collision which affected the network performance badly. Hubs were the bottleneck no.1

Long ago, I tried to check sniffing on a hub based network. Just using a sniffer on the attacker’s machine and you can see the traffic between all the machines connected to the hub.

If the traffic is sent from victim1 to victim2, the hub sends the traffic from port 1 to all the other ports, and then other machines just drop the traffic coz they don’t match the destination IP / Mac in the header parts.

If you try something like ethereal now on your machine in a switched network, you get nothing. Just the traffic from / to your machine only..

Why??

It is because you have a switch.

In a switched Network:

The switch controls the collision domains. The switch has some memory to know which machine is connected to which port. This is all based on the Mac Addresses. (while the hub doesn’t really care about that stuff). So if the traffic is sent from victim1 to victim2 on a switch, the attacker can’t get the traffic because the switch sends the traffic from port 1 to port 2.

The Idea of sniffing in a switched network:

So, in a switched network you need the switch to send the traffic from victim1 to the attacker which then sends it back to victim 2. The attacker machine then acts as a ‘Router’. It routes the traffic from victim 1 to victim 2 through it. This is what we simply call the “MIM” or “Main In the Middle” Attack.

MIM is done by altering the Arp Tables by a process called “ARP Poisoning”.

So how is the ARP Poisoning done??

ARP: Address resolution Protocol.

Its role is to map IP addresses to the MAC addresses.

In victim 1:

ARP Table has these entries:

IP: 10.0.0.2

MAC:  00-00-00-00-00-02

But after poisoning

IP : 10.0.0.2

MAC: 00-00-00-00-00-10

So, the traffic is sent to the attacker’s machine

The same stuff is on Victim 2 ‘s ARP table:

Before Poisoning :

IP:  10.0.0.1

MAC: 00-00-00-00-00-01

After Poisoning:

IP: 10.0.0.1

MAC: 00-00-00-00-00-10

When a machine is on a network, it sends an ARP Request saying “ Who has the IP Address 10.0.0.2” ?

Then machine 10.0.0.2 sends the ARP Reply that machine with the MAC 00-00-00-00-00-02 has the 10.0.0.2 address.

The good news (or bad  ... I don’t know) is that machines can respond to an ARP Reply message even if they don’t make a request. So, the Arp poisoning goes flooding the Arp tables by incorrect ARP Reply messages with MAC addresses to change the IP / MAC mapping.

You don’t need to do this stuff manually.

The tools that you use for sniffing in a switched network can do this stuff for you.

How to stop something like that?

. IPSec signs the hops / path that the packets travel from source to destination. So, if any of the hops is altered, the packet is rejected. (I’ll try to make some detailed posts on IPSec later).

Working for Microsoft, one of the biggest companies ever in the world, has been a dream to lots of people.

Microsoft has been selected as one of the best 100 companies to work for ( http://money.cnn.com/magazines/fortune/bestcompanies/2007/full_list/ ). It is number 50.

You get lots of great benefits when you work for Microsoft. (Differs according to the location) and the biggest benefit is having one of your dreams come true.

You can apply on the Microsoft careers site to work or have an internship. (http://www.microsoft.com/careers/ ) There is a very big chance for MBA holders to work for Microsoft.

SQL express edition is a very nice Database Engine for developers to work on it while developing their database applications.

My first experience with SQL server was SQL Server 2000 Standard Edition. But, when I began to try the SQL Express editions with Visual Studio Express  and began to use the SQL 2005 Express edition, I felt like working BLINDLY !!!! I couldn’t find the Enterprise Manager !!

Well ..

You can download the SQL Server Management Studio Express from (http://www.microsoft.com/downloads/details.aspx?FamilyID=c243a5ae-4bd1-4e3d-94b8-5a0f62bf7796&displaylang=en )

Are you a hobbyist? A student?

Now the Visual Studio 2008 Express Edition is available for download for free at http://www.microsoft.com/express/download/