Viruses
Free software infected with viruses and trojans. You will need a good antivirus and make sure you have always the latest updates. Only download files from respected sources and you should be just fine. You can get some free stuff on our website. We try to test all freebies first.
Server security holes
If you run a website, be aware of any holes that may expose you to hacking. A security hole can make someone else take control of your website and use it for illegal purposes and guess what... you will face the consequences. Avoid as much as possible opensource software, specially if it's not updated for a long time.
Trial subscriptions
Those are freebies that aren't really freebies. They usually ask for your financial informations in order to get access to that particular freebie. Open your eyes wide when you enter such informations... every respectable website should have a security certificate on that page. Check it and see if the certificate is genuine. Do not enter paypal details on pages outside www.paypal.com, do not enter moneybookers details on pages outside www.moneybookers.com. Check the domain and if you spot something wrong get out of there and report them.
Shipping and handling
A freebie that require you to pay for shipping and handling isn't really free anymore, is it? That don't mean is not worth it... I would pay shipping and handling for a free plasma TV. But this can also be a trick... watch the domains that ask for credit card details the same way as for trial subscriptions. If anything looks suspicious, do not enter any financial details.
Email
When you try to access freebie directories, you still have to register and provide them with your email address. Look for privacy policy... some websites will sign you up for tones of spam newsletter and some will even sell your email address. An active email address is worth from 0,05$ up to 5$ on the black market. You all know what i mean... pharma stores that spawn everywhere, dating websites that send you 5-6 emails a day and so on.
The bottom line is that you are your best antivirus. Just keep your eyes open and don't click any link that pops in front of your eyes. Read, think and analyze everything.
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Tuesday, May 10, 2011
5 Security Considerations When Coding
1. Input Checking
Always check user input to be sure that it is what you expected. Make sure it doesn’t contain characters or other data which may be treated in a special way by your program or any programs called by your program.This often involves checking for characters such as quotes, and checking for unusual input characters such as non-alphanumeric characters where a text string is expected. Often, these are a sign of an attack of some kind being attempted.
2.Range Checking
Always check the ranges when copying data, allocating memory or performing any operation which could potentially overflow. Some programming languages provide range-checked container access (such as the std::vector::at() in C++, but many programmers insist on using the unchecked array index [] notation. In addition, the use of functions such as strcpy() should be avoided in preference to strncpy(), which allows you to specify the maximum number of characters to copy. Similar versions of functions such as snprintf() as opposed to sprintf() and fgets() instead of gets() provide equivalent length-of-buffer specification. The use of such functions throughout your code should prevent buffer overflows. Even if your character string originates within the program, and you think you can get away with strcpy() because you know the length of the string, that doesn’t mean to say that you, or someone else, won’t change things in the future and allow the string to be specified in a configuration file, on the command-line, or from direct user input. Getting into the habit of range-checking everything should prevent a large number of security vulnerabilities in your software.
3.Principle Of Least Privileges
This is especially important if your program runs as root for any part of its runtime. Where possible, a program should drop any privileges it doesn’t need, and use the higher privileges for only those operations which require them. An example of this is the Postfix mailserver, which has a modular design allowing parts which require root privileges to be run distinctly from parts which do not. This form of privilege separation reduces the number of attack paths which lead to root privileges, and increases the security of the entire system because those few paths that remain can be analysed critically for security problems.
4.Don’t Race
A race condition is a situation where a program performs an operation in several steps, and an attacker has the chance to catch it between steps and alter the system state. An example would be a program which checks file permissions, then opens the file. Between the permission check the stat() call and the file open the fopen() call an attacker could change the file being opened by renaming another file to the original files name. In order to prevent this, fopen() the file first, and then use fstat(), which takes a file descriptor instead of a filename. Since a file descriptor always points to the file that was opened with fopen(), even if the filename is subsequently changed, the fstat() call will be guaranteed to be checking the permissions of the same file. Many other race conditions exist, and there are often ways to prevent them by carefully choosing the order of execution of certain functions.
5.Register Error Handlers
Many languages support the concept of a function which can be called when an error is detected, or the more flexible concept of exceptions. Make use of these to catch unexpected conditions and return to a safe point in the code, instead of blindly progressing in the hope that the user input won’t crash the program, or worse!
Always check user input to be sure that it is what you expected. Make sure it doesn’t contain characters or other data which may be treated in a special way by your program or any programs called by your program.This often involves checking for characters such as quotes, and checking for unusual input characters such as non-alphanumeric characters where a text string is expected. Often, these are a sign of an attack of some kind being attempted.
2.Range Checking
Always check the ranges when copying data, allocating memory or performing any operation which could potentially overflow. Some programming languages provide range-checked container access (such as the std::vector::at() in C++, but many programmers insist on using the unchecked array index [] notation. In addition, the use of functions such as strcpy() should be avoided in preference to strncpy(), which allows you to specify the maximum number of characters to copy. Similar versions of functions such as snprintf() as opposed to sprintf() and fgets() instead of gets() provide equivalent length-of-buffer specification. The use of such functions throughout your code should prevent buffer overflows. Even if your character string originates within the program, and you think you can get away with strcpy() because you know the length of the string, that doesn’t mean to say that you, or someone else, won’t change things in the future and allow the string to be specified in a configuration file, on the command-line, or from direct user input. Getting into the habit of range-checking everything should prevent a large number of security vulnerabilities in your software.
3.Principle Of Least Privileges
This is especially important if your program runs as root for any part of its runtime. Where possible, a program should drop any privileges it doesn’t need, and use the higher privileges for only those operations which require them. An example of this is the Postfix mailserver, which has a modular design allowing parts which require root privileges to be run distinctly from parts which do not. This form of privilege separation reduces the number of attack paths which lead to root privileges, and increases the security of the entire system because those few paths that remain can be analysed critically for security problems.
4.Don’t Race
A race condition is a situation where a program performs an operation in several steps, and an attacker has the chance to catch it between steps and alter the system state. An example would be a program which checks file permissions, then opens the file. Between the permission check the stat() call and the file open the fopen() call an attacker could change the file being opened by renaming another file to the original files name. In order to prevent this, fopen() the file first, and then use fstat(), which takes a file descriptor instead of a filename. Since a file descriptor always points to the file that was opened with fopen(), even if the filename is subsequently changed, the fstat() call will be guaranteed to be checking the permissions of the same file. Many other race conditions exist, and there are often ways to prevent them by carefully choosing the order of execution of certain functions.
5.Register Error Handlers
Many languages support the concept of a function which can be called when an error is detected, or the more flexible concept of exceptions. Make use of these to catch unexpected conditions and return to a safe point in the code, instead of blindly progressing in the hope that the user input won’t crash the program, or worse!
Subscribe to:
Posts (Atom)