downloads | documentation | faq | getting help | mailing lists | licenses | wiki | reporting bugs | sites | links | conferences | my

search for in the

Installed as CGI binary> <Introduction
[edit] Last updated: Fri, 22 Jul 2011

view this page in

General considerations

A completely secure system is a virtual impossibility, so an approach often used in the security profession is one of balancing risk and usability. If every variable submitted by a user required two forms of biometric validation (such as a retinal scan and a fingerprint), you would have an extremely high level of accountability. It would also take half an hour to fill out a fairly complex form, which would tend to encourage users to find ways of bypassing the security.

The best security is often unobtrusive enough to suit the requirements without the user being prevented from accomplishing their work, or over-burdening the code author with excessive complexity. Indeed, some security attacks are merely exploits of this kind of overly built security, which tends to erode over time.

A phrase worth remembering: A system is only as good as the weakest link in a chain. If all transactions are heavily logged based on time, location, transaction type, etc. but the user is only verified based on a single cookie, the validity of tying the users to the transaction log is severely weakened.

When testing, keep in mind that you will not be able to test all possibilities for even the simplest of pages. The input you may expect will be completely unrelated to the input given by a disgruntled employee, a cracker with months of time on their hands, or a housecat walking across the keyboard. This is why it's best to look at the code from a logical perspective, to discern where unexpected data can be introduced, and then follow how it is modified, reduced, or amplified.

The Internet is filled with people trying to make a name for themselves by breaking your code, crashing your site, posting inappropriate content, and otherwise making your day interesting. It doesn't matter if you have a small or large site, you are a target by simply being online, by having a server that can be connected to. Many cracking programs do not discern by size, they simply trawl massive IP blocks looking for victims. Try not to become one.

Installed as CGI binary> <Introduction
[edit] Last updated: Fri, 22 Jul 2011
add a note add a note User Contributed Notes General considerations
alex 08-Apr-2008 03:53
well, if you're a skilled php programmer, you can avoid many of these dangers..

for example xss...   as its the most common attack, filter all the input you gain from the user (not only with htmlspecialchars but also with more personalized string-checks for specific words and chars like document.location and so on).

or file injection (filter out ../  and so on).

i admit that php has its weakpoints (sessions...), but nothing is 100% secure (but you can use ssl for high security projects..)
Abdul Basit 30-Jul-2007 05:59
No doubt PHP is a strong language and it gain power during its evaluation.But there are too much security risks in PHP.Most  common are :
1-Invalidated Input Errors
2-Access Control Flaws
3-Session ID Protection
4-Cross Site Scripting (XSS) Attacks
5-SQL Injection Vulnerabilities
6-Error Reporting
7-Data Handling Errors
8-PHP configuration settings
As PHP is open-sourse server-side scripting language, it is most often uses in web applications and database-driven web site which obviously have critical data.So malicious users always try to find holes in its security, in other word this open-source is in focus of attackers.Thus it becomes the responsiblity of developer to minimize the securiy risks in  product.
ms_sux_2000 at hotmail dot com 11-Dec-2006 05:34
Emacs doesn't require an X server to run, you can use the command line option '-nw' to start emacs in that console.  Also portmap isn't required by an X server nor emacs (except maybe for special optional packages).
yairl at savion dot huji dot ac dot il 25-Apr-2006 10:14
Important Security Note for emacs users

Many linux/unix developers like the emacs editor to write code. It's a great editor with many features for PHP/Perl developers. emacs by default creates a back up file ending with ~. Then when you create a file myprogram.php it creates a back up file myprogram.php~ . You can change this default behavoir  to avoid emacs creates this file but many people prefer to keep this default. The problem is that through the webserver people can load this file ending with ~ and can see your php code because the webserver doesn't parser this file as php type due to the ~. This behavoir is a strong security hole, it permits to everybody to see and hack your code. i recommend to emacs users to deny access to files ending with ~ in general to avoid this problem.
In general PHP developers must check that the editor they are using is not creating a file beside the php source file without the end file name .php necessary for the webserver to parser it as php application.

in apache webserver you can deny access to these files with the following configure order

<File "*~">
Deny  all
henke dot andersson at comhem dot se 25-Dec-2005 08:53
A good tactic to employ is the "least privileged needed" aproatch. If a aplication is only reading from a particular table in a particular database, it should have a account that can do exactly that and no more.

show source | credits | sitemap | contact | advertising | mirror sites