PHP
downloads | documentation | faq | getting help | mailing lists | reporting bugs | php.net sites | links | conferences | my php.net

search for in the

CGI バイナリとしてインストール> <はじめに
Last updated: Fri, 22 Aug 2008

view this page in

一般的な考慮事項

完全に安全なシステムは理想の産物でしかないため、セキュリティ業界で しばしば使用される手法は、リスクと利便性のバランスのとれた手法です。 変数がユーザから投稿される度に(網膜スキャンと指紋のような)2種類の 生体認証が必要だとしたら、極端に高いレベルの説明義務を生じます。ま た、かなり複雑なフォームを埋めるために30分もかかるとすれば、ユーザ がセキュリティをバイパスする手段を探す気分にさせる傾向があります。

最善のセキュリティは、通常、ユーザによる業務の達成を防たげずに要求 を十分に達成できる程度にさしでがましくないものです。むしろ、いくつ かのセキュリティ攻撃は、単純にこの種の多げさに構築され、時間を浪費 しがちなセキュリティ機構を狙うものです。

記憶するに値する言葉として次のようなものがあります。「システムは鎖 の最も弱い輪と同程度に優れている」全てのトランザクションが時間、場 所、トランザクションの型等に基づき大量に記録されているが、ユーザは 一つのクッキーのみにより認証されている場合、ユーザとそのトランザク ションログの結び付きの確実性はかなり弱くなります。

テストの際に、最も簡単なページに関してでさえ、全ての可能性をテスト することは不可能であるということを頭に入れておいてください。期待する 入力は、不機嫌な社員、経験のあるクラッカー、キーボードの上を歩く家 の猫による入力とは全く無関係でしょう。これが、想定外のデータが入力 される可能性がある場所を見分けるために論理的な視点からコードを見て、 その後、修正、減少、または詳細に調べるというのが、最善であるという 理由です。

インターネットにはあなたのコードを壊したり、システムを破壊したり、 不適切な内容を投稿したり、その他あなたの一日を不快にするようなこと により自分の名を馳せたいと思う人がたくさんいます。サイトの規模の大 小によらず、単にオンラインであり、接続できるサーバを有しているだけ で攻撃目標となりえます。多くのクラック用プログラムはサイトの大きさ を考慮せず、犠牲者を探しつつ大きなIPブロックで網を張っています。 その犠牲者の一人にならないようにしてください。



CGI バイナリとしてインストール> <はじめに
Last updated: Fri, 22 Aug 2008
 
add a note add a note User Contributed Notes
一般的な考慮事項
alex
08-Apr-2008 11: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 01: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.
Andreas R dot newsgroups2005 at geekmail dot de
04-Apr-2007 01:02
In reply to: yairl at savion dot huji dot ac dot il (Important Security Note for emacs users)
> in apache webserver you can deny access to these files with the following configure order
>  <File "*~">
> Deny  all
> </File>

If you want to use .htaccess file, it should be:
<Files "*~">
Deny from all
</Files>

But then don't forget to set AllowOverride All (for the directory in question), e.g.
<Directory /var/www/localhost/htdocs>
    AllowOverride All
</Directory>
since with the (default?) AllowOverride None the .htaccess files are ignored, see
http://issues.apache.org/bugzilla/show_bug.cgi?id=41760
ms_sux_2000 at hotmail dot com
11-Dec-2006 12: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).
lesley_b_linux at yahoo dot co dot uk
18-Oct-2006 10:19
In answer to the first poster here, you shouldn't really be developing within the tree of a live Internet facing web server at all ever.

All Linux distro's I have come across have the capability of running Apache on the localhost so at it's simplest level you should :-

0.  Get the latest web site code from your version control system.
1. Do your development using the localhost web server
2.  Check in your new site code to the version control system you are running.
3. Upload only the new or updated files to the active webserver

You can use anything from ftp to sitecopy to upload your files and most advanced site copying tools allow you to ignore *.bak  *~ or even entire directories if you need to.

If you must develop on the server, then ssh in and use vi but look out for disconnects leaving vi .*.swp files aorund.  (Why use vi? Because then you aren't exposing the web server to further insecurity by running the portmap deamon for the X-server required for emacs. )

That's speaking as someone who uses both emacs and vi.
yairl at savion dot huji dot ac dot il
25-Apr-2006 06: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 03: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.

CGI バイナリとしてインストール> <はじめに
Last updated: Fri, 22 Aug 2008
 
 
show source | credits | sitemap | contact | advertising | mirror sites