Einführung
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
Allgemeine Überlegungen
Ein komplett sicheres System ist praktisch ein Ding der Unmöglichkeit, weshalb ein unter Sicherheitsprofis oft genutzter Ansatz ist, einen Mittelweg zwischen Risiko und Verwendbarkeit zu finden. Wenn jede von einem Benutzer übermittelte Variable zwei Formen von biometrischer Prüfung (wie z.B. ein Scan der Netzhaut und ein Fingerabdruck) verlangen würde, wäre eine extrem hohe Ebene der Verantwortlichkeit erreicht. Ein sehr komplexes Formular auszufüllen würde auch eine halbe Stunde in Anspruch nehmen, die Benutzer dazu ermuntern könnte, Wege zur Umgehung der Sicherheitsmaßnahmen zu suchen.
Die beste Sicherheit ist oft unaufdringlich genug, um den Anforderungen zu entsprechen, ohne den Benutzer an seiner Arbeit zu hindern oder den Code-Autor mit übertriebener Komplexität zu überlasten. Tatsächlich sind einige Sicherheitsangriffe nur die Folge von allzu strengen Sicherheitsmaßnahmen, was mit der Zeit nur zu deren Unterminierung führt.
Eine Phrase, die es wert ist, sich an sie zu erinnern: Ein System ist nur so gut wie das schwächste Glied in der Kette. Wenn alle Transaktionen mittels Zeit, Ort, Transaktionstyp, etc. streng mitprotokolliert werden, der Benutzer aber nur mittels eines einzigen Cookies verifiziert wird, lässt die Zuverlässigkeit für die Bindung des Benutzers an das Transaktions-Log bedrohlich nach.
Denken Sie während der Tests daran, dass Sie selbst für die einfachsten Seiten nicht alle Möglichkeiten testen können. Der von Ihnen vielleicht erwartete Input wird zu dem eines verstimmten Mitarbeiters oder eines Crackers, der Monate Zeit hat, oder einer Katze, die über die Tastatur läuft, in keinerlei Zusammenhang stehen. Deshalb betrachten Sie Ihren Code am Besten aus der logischen Perspektive, um zu erkennen, wo unerwartete Daten eingebracht werden können und fragen sich dann, wie diese modifiziert, reduziert, oder weiter ausgeführt werden.
Das Internet ist voll von Leuten, die versuchen, sich durch Entschlüsseln/Zerstören Ihres Codes, den Zusammenbruch Ihres Systems, Einsetzen von unangebrachten Inhalten, und anderen, Ihren Tag interessant gestaltenden Maßnahmen, einen Namen zu machen. Es ist egal, ob Sie eine kleine oder große Site haben, Sie sind einfach ein Ziel, wenn Sie online sind oder wenn Sie einen Server haben, zu dem man eine Verbindung aufbauen kann. Viele Cracker-Programme erkennen nicht die Größe, sondern durchsieben einfach gewaltige IP-Blöcke im Netz, um Opfer zu finden. Versuchen Sie, keines zu werden.
add a note
User Contributed NotesAllgemeine Überlegungen
Andreas R dot newsgroups2005 at geekmail dot de
04-Apr-2007 07:02
04-Apr-2007 07:02
ms_sux_2000 at hotmail dot com
11-Dec-2006 06:34
11-Dec-2006 06: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 04:19
18-Oct-2006 04: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 12:14
25-Apr-2006 12: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 09:53
25-Dec-2005 09: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.