도입
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..)
일반적인 고려 사항
완벽한 보안 시스템은 불가능에 가깝기에, 보안 대책의 지향점은 보통 위험성과 사용성의 조화점입니다. 유저가 송신하는 모든 변수가 두가지 형태의 생물학적 인증(망막 스캔이나 지문 등)이 필요하다면, 매우 높은 수준의 보안을 얻을 수 있습니다. 그러나 이 방법은 매우 복잡한 폼을 채우기 위해 30여분의 시간을 필요로 할 것이며, 유저가 보안을 그냥 넘어갈 수 있는 방법을 찾도록 노력하게 할 것입니다.
필요 이상의 엄중한 보안은 종종 사용자가 작업을 하는 것을 방해하거나, 지나친 복잡함으로 코드 작성자에게 부담을 줍니다. 사실, 몇몇 보안 공격은 지나친 보안으로 인한 약점을 노리며, 시간을 들여 손상시키는 경향이 있습니다.
기억할만한 문구입니다: 시스템은 체인의 가장 약한 부분 정도에 불과하다. 모든 작업을 시간, 장소, 작업 종류 등으로 자세하게 기록을 한다고 하여도, 사용자 인증을 하나의 쿠키로만 처리한다면, 사용자에 대한 작업 기록은 매우 약해질 것입니다.
테스트를 할 때, 가장 간단한 페이지라 할지라도 모든 가능성을 테스트할 수는 없다는 것을 명심하십시오. 화가 난 고용인이나, 엄청난 시간을 가진 크랙커, 혹은 키보드 위를 걸어가는 고양이 등에 의해 기대했던 입력값과는 완전히 무관하게 될 수도 있습니다. 이것이 기대하지 않는 데이터를 분별하고, 그 뒤에 어떻게 변경하고, 줄이고, 늘릴지에 대해 논리적 관점에서 코드를 바라보아야 할 이유입니다.
인터넷은 당신의 코드를 부수고, 사이트를 파괴하고, 부적절한 내용을 게시하는 등 당신을 바쁘게 하는 사람들로 가득 차 있습니다. 사이트의 크기에 관계 없이, 온라인인 서버를 가지고 있다면 간단히 목표가 됩니다. 많은 크래킹 프로그램은 크기를 고려하지 않으며, 단지 IP 블럭에서 희생자를 찾을 뿐입니다. 희생자가 되지 마십시오.
add a note
User Contributed Notes일반적인 고려 사항
alex
08-Apr-2008 03:53
08-Apr-2008 03:53
Abdul Basit
30-Jul-2007 05:59
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
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
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
</File>
henke dot andersson at comhem dot se
25-Dec-2005 08:53
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.