aprendiendophp
Aprendiendo juntos PHP y MySQL, como complemento de otras herramientas Web, para comercio, paginas personales, etc, bases de datos, foros, etc.-
|
| | Foro | Temas | Mensajes | Últimos Mensajes |
|---|
| |  |  PHP es un poderoso lenguaje e intérprete, ya sea incluido como parte de un servidor web en forma de módulo o ejecutado como un binario CGI separado, es capaz de acceder a archivos, ejecutar comandos y abrir conexiones de red en el servidor. Estas propiedades hacen que cualquier cosa que sea ejecutada en un servidor web sea insegura por naturaleza. PHP está diseñado específicamente para ser un lenguaje más seguro para escribir programas CGI que Perl o C, y con la selección correcta de opciones de configuración en tiempos de compilación y ejecución, y siguiendo algunas prácticas correctas de programación, PHP le puede dar la combinación precisa de libertad y seguridad que usted necesita.Ya que hay muchas maneras de utilizar PHP, existen varias opciones de configuración diseñadas para controlar su comportamiento. Un amplio rango de opciones le garantizan que pueda usar PHP para muchos propósitos distintos, pero también quiere decir que hay combinaciones de éstas opciones y configuraciones de servidor que pueden resultar en un entorno inseguro.El nivel de flexibilidad en la configuración de PHP se compara quizás solo con su flexibilidad de desarrollo. PHP puede ser usado para escribir aplicaciones completas de servidor, con todo el poder de un usuario de un intérprete de comandos, o puede ser usado para inclusiones simples del lado del servidor con muy poco riesgo en un entorno minuciosamente controlado. Cómo construir ese entorno, y qué tan seguro es, básicamente depende del desarrollador PHP.Este capítulo comienza con algunas recomendaciones generales de seguridad, explica las diferentes combinaciones de opciones de configuración y las situaciones en las que pueden ser usadas con seguridad, y describe diferentes consideraciones a la hora de programar para diferentes niveles de seguridad.
Moderador: Moderadores
| 23 | 23 | Jue Ago 04, 2011 3:04 pm
beaphpar  | | |  Consideraciones generalesUn sistema completamente seguro es prácticamente un imposible, de modo que el enfoque usado con mayor frecuencia en la profesión de seguridad es uno que busque el balance adecuado entre riesgo y funcionalidad. Si cada variable enviada por un usuario requiriera de dos formas de validación biométrica (como rastreo de retinas y análisis dactilar), usted contaría con un nivel extremadamente alto de confiabilidad. También implicaría que llenar los datos de un formulario razonablemente complejo podría tomar media hora, cosa que podría incentivar a los usuarios a buscar métodos para esquivar los mecanismos de seguridad.La mejor seguridad con frecuencia es lo suficientemente razonable como para suplir los requerimientos dados sin prevenir que el usuario realice su labor de forma natural, y sin sobrecargar al autor del código con una complejidad excesiva. De hecho, algunos ataques de seguridad son simples recursos que aprovechan las vulnerabilidades de este tipo de seguridad sobrecargada, que tiende a erosionarse con el tiempo.Una frase que vale la pena recordar: Un sistema es apenas tan bueno como el eslabón más débil de una cadena. Si todas las transacciones son registradas copiosamente basándose en la fecha/hora, ubicación, tipo de transacción, etc. pero la verificación del usuario se realiza únicamente mediante una cookie sencilla, la validez de atar a los usuarios al registro de transacciones es mermada severamente.Cuando realice pruebas, tenga en mente que no será capaz de probar todas las diferentes posibilidades, incluso para las páginas más simples. Los datos de entrada que usted puede esperar en sus aplicaciones no necesariamente tendrán relación alguna con el tipo de información que podría ingresar un empleado disgustado, un cracker con meses de tiempo entre sus manos, o un gato doméstico caminando sobre el teclado. Es por esto que es mejor observar el código desde una perspectiva lógica, para determinar en dónde podrían introducirse datos inesperados, y luego hacer un seguimiento de cómo esta información es modificada, reducida o amplificada.Internet está repleto de personas que tratan de crearse fama al romper la seguridad de su código, bloquear su sitio, publicar contenido inapropiado, y por lo demás haciendo que sus días sean más interesantes. No importa si usted administra un sitio pequeño o grande, usted es un objetivo por el simple hecho de estar en línea, por tener un servidor al cual es posible conectarse. Muchas aplicaciones de cracking no hacen distinciones por tamaños, simplemente recorren bloques masivos de direcciones IP en busca de víctimas. Trate de no convertirse en una.Instalación como un binario CGI> in apache webserver you can deny access to these files with the following configure order> > Deny all> If you want to use .htaccess file, it should be:Deny from allBut then don't forget to set AllowOverride All (for the directory in question), e.g. AllowOverride Allsince with the (default?) AllowOverride None the .htaccess files are ignored, seehttp://issues.apache.org/bugzilla/show_bug.cgi?id=41760ms_sux_2000 at hotmail dot com11-Dec-2006 09:34Emacs 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 uk18-Oct-2006 07:19In 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 server2. 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 webserverYou 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 il25-Apr-2006 03:14Important Security Note for emacs usersMany 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 orderDeny all
| 6 | 6 | Jue Ago 04, 2011 3:04 pm
beaphpar | | |  Instalación como módulo de ApacheCuando PHP es usado como un módulo de Apache, hereda los permisos del usuario de Apache (generalmente los del usuario "nobody"). Este hecho representa varios impactos sobre la seguridad y las autorizaciones. Por ejemplo, si está usando PHP para acceder a una base de datos, a menos que tal base de datos disponga de un control de acceso propio, usted tendrá que hacer que la base de datos sea asequible por el usuario "nobody". Esto quiere decir que un script malicioso podría tener acceso y modificar la base de datos, incluso sin un nombre de usuario y contraseña. Es completamente posible que un archivador automatizado de documentos web pudiera toparse con la página web de administración de una base de datos, y eliminar todas sus bases de datos. Usted puede protegerse de este tipo de situaciones mediante mecanismos de autorización de Apache, o puede diseñar su propio modelo de acceso usando LDAP, archivos .htaccess, etc. e incluir ese código como parte de sus scripts PHP.Con frecuencia, una vez la seguridad se ha establecido en un punto en donde el usuario de PHP (en este caso, el usuario de apache) tiene asociada una muy leve capacidad de riesgo, se descubre que PHP se encuentra ahora imposibilitado de escribir archivos en los directorios de los usuarios. O quizás se le haya desprovisto de la capacidad de acceder o modificar bases de datos. Se ha prevenido exitosamente que pudiera escribir tanto archivos buenos como malos, o que pudiera realizar transacciones buenas o malas en la base de datos.Un error de seguridad cometido con frecuencia en este punto es darle permisos de administrador (root) a apache, o incrementar las habilidades del usuario de apache de alguna otra forma.Escalar los permisos del usuario de Apache hasta el nivel de administrador es extremadamente peligroso y puede comprometer al sistema entero, así que el uso de entornos sudo, chroot, o cualquier otro mecanismo que sea ejecutado como root no debería ser una opción viable para aquellos que no son profesionales en seguridad.Existen otras soluciones más simples. Mediante el uso de open_basedir usted puede controlar y restringir aquellos directorios que podrían ser usados por PHP. También puede definir áreas solo-Apache, para restringir todas las actividades basadas en web a archivos que no son de usuarios, o del sistema.Seguridad del sistema de archivos> ServerName www.example.com DocumentRoot /www-home/example.com[...] php_admin_value open_basedir \ "/www-home/example.com/:/usr/lib/php/" If you set safe_mode on, then the script can only use binaries in given directories (make a special dir only with the binaries your customers may use).Now no user of a virtual host can read/write/modify the data of another user on your machine.Windseekeradd a note add a noteSeguridad del sistema de archivos> | 0 | 0 | | | |  Uso de Register GlobalsWarningThis feature has been DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.Quizás el cambio más controversial en la historia de PHP se ha dado cuando la directiva register_globals pasó de tener como valor por defecto ON al valor OFF en PHP » 4.2.0. La dependencia sobre esta directiva era bastante común y muchas personas nisiquiera estaban enteradas de que existía y asumían que ese era el modo en que PHP trabajaba. Esta página explicará cómo puede llegar a escribirse código inseguro con esta directiva pero tenga en mente que no es la directiva misma la que es insegura sino el uso inapropiado de ella.Cuando se encuentra activa, la directiva register_globals inyectará sus scripts con todo tipo de variables, como variables de peticiones provenientes de formularios HTML. Esto junto con el hecho de que PHP no requiere la inicialización de variables significa que es muy fácil escribir código inseguro. Fue una decisión difícil, pero la comunidad de PHP decidió desahibilar esta directiva por defecto. Cuando está habilitada, las personas usan variables sin saber con seguridad de dónde provienen y solo queda asumir. Las variables internas que son definidas en el script mismo son mezcladas con los datos enviados por los usuarios y al deshabilitar register_globals se modifica este comportamiento. Demostremos este caso con un ejemplo del uso incorrecto de register_globals:Example #1 Ejemplo del uso inapropiado de register_globals = onCuando register_globals = on, nuestra lógica anterior podría verse comprometida. Cuando la directiva está deshabilitada, $autorizado no puede definirse a través de peticiones, así que no habrá ningún problema, aunque es cierto que siempre es una buena práctica de programación inicializar las variables primero. Por ejemplo, en nuestro ejemplo anterior pudimos haber realizado primero algo como $authorized = false. Hacer esto representa que el código anterior podría funcionar con register_globals establecido a on u off ya que los usuarios no serían autorizados por omisión.Otro ejemplo es aquel de las sesiones. Cuando register_globals = on, podríamos usar también $nombre_usuario en nuestro siguiente ejemplo, pero nuevamente usted debe notar que $nombre_usuario puede provenir de otros medios, como GET (a través de la URL).Example #2 Ejemplo del uso de sesiones con register_globals on u off{$_SESSION['nombre_usuario']}";} else { echo "Hola Invitado
"; echo "¿Quisiera iniciar su sesión?";}?>Incluso es posible tomar medidas preventivas para advertir cuando se intente falsificar la información. Si usted sabe previamente con exactitud el lugar de donde debería provenir una variable, usted puede chequear si los datos enviados provienen de una fuente inadecuada. Aunque esto no garantiza que la información no haya sido falsificada, esto requiere que un atacante adivine el medio apropiado para falsificar la información. Si no le importa de dónde proviene la información, puede usar $_REQUEST ya que allí se incluye una mezcla de variables que provienen de datos GET, POST y COOKIE. Consulte también la sección del manual sobre el uso de variables desde fuera de PHP.Example #3 Detección de envenenamiento simple de variablesPor supuesto, deshabilitar register_globals no quiere decir que su código vaya a ser seguro. Por cada trozo de datos que sea enviado por el usuario, éste debe ser chequeado en otras formas. ¡Siempre valide los datos de los usuarios e inicialice sus variables! Para chequear por variables no inicializadas, usted puede usar error_reporting() para mostrar errores del nivel E_NOTICE.Para más información sobre la emulación del valor On u Off de register_globals, consulte este FAQ. Note: Superglobals: Nota de disponibilidad Desde 4.1.0, están disponibles algunas matrices superglobales tales como $_GET, $_POST, y $_SERVER, etc. Para más información puede consultar la sección superglobalsDatos Enviados por el Usuario> $value) { if (isset($GLOBALS[$key])) unset($GLOBALS[$key]); } }}unregister_globals('_POST', '_GET', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES');?>moore at hs-furtwangen dot de14-Jul-2008 01:19I had a look at the post from Dice, in which he suggested the function unregister_globals(). It didn't seem to work - only tested php 4.4.8 and 5.2.1 - so I made some tweaking to get it running. (I had to use $GLOBALS due to the fact that $$name won't work with superglobals). $var) { if (isset($GLOBALS[$key]) && $var === $GLOBALS[$key]) { //echo 'found '.$key.' = '.$var.' in $'.$value."\n"; unset($GLOBALS[$key]); } } } } }}?>The echo was for debuging, thought it might come in handy.stranger at teuton dot org10-Jul-2008 04:48RE: Anonymous on oirinely at yahoo dot comActually oirinely is correct. With register_globals on any key in $_SESSION becomes a global variable when session_start() happens. This means that assigning a value to any variable that has the same name as any existing $_SESSION key (when register_globals is on and session_start() has happened) is the same as assigning to $_SESSIONe.g.result = 1Anonymous28-Apr-2008 04:14oirinely at yahoo dot com -that piece of code will not print another value unless it looks like this:fab dot mariotti at [google]gmail dot com16-Apr-2008 12:59For my application I defined two functions:wit_set_gv('space','key','value')wit_get_gv('space','key')Forgive the "wit_" prefix but the gv stays for Global Variable.Maybe I should start with a simple version:wit_set_gv('key','value')wit_get_gv('key')This way you would set or get a global/session value.The register_globals (on or off), session state and/orsuperglobal variables will be handled by these functions.I did add a 'space' item because I wanted to have controlon what goes to/comes from where. As an example if I call:wit_get_gv('WIT_CONF','URL')I know that I have to check for a global variable namedWIT_CONF which also gives me a positive responceon isset($WIT_CONF['URL']). In this case $WIT_CONFis global and static. But I can also set up a $WIT_STATEvariable which will represent the state of the transaction.Using the code of WIT_set_gv() and WIT_get_gv(), with the helpof a simple few lines (in my case: include globals.inc.php)definition script I handle this problem.In my case, for example, if 'WIT_STATE' (or other names)is not a defined globally available variable I default to checkfor a session variable.For example you might warn or stop if a requested named variablematches a $_POST, $_GET or $_SESSION variable name while youdo not expect so. i.e. all my private data has a wit_ prefixbut no public request has (shouldn't have) this prefix.Oopss. I do realize that this comment might not be in the properplace. i.e. "register_globals". Indeed it might give some adviceto users still using register_globals and willing to change thecode for a "better" solution. Of course the simple switching to "register_globals = off" might not solvethe securities issues.CheersFDice15-Apr-2008 09:46To expand on the nice bit of code Mike Willbanks wrote and Alexander tidied up, I turned the whole thing in a function that removes all the globals added by register_globals so it can be implemented in an included functions.php and doesn't litter the main pages too much. $var) { if ($var === $GLOBALS[$key]) { unset($GLOBALS[$key]); } } } }}?>Ruquay K Calloway01-Apr-2008 06:59While we all appreciate the many helpful posts to get rid of register_globals, maybe you're one of those who just loves it. More likely, your boss says you just have to live with it because he thinks it's a great feature.No problem, just call (below defined):anywhere, as often as you want. Or update your scripts! $value) { global $$varname; $$varname = $value; } } } $order = explode("\r\n", trim(chunk_split($order, 1))); foreach($order as $k) { switch(strtolower($k)) { case 'e': register_global_array($_ENV); break; case 'g': register_global_array($_GET); break; case 'p': register_global_array($_POST); break; case 'c': register_global_array($_COOKIE); break; case 's': register_global_array($_SERVER); break; } }}?>subarea20-Mar-2008 09:43If you have no access to php.ini and the solution withthe .htaccess entry (php_flag register_globals 0)also doesn't work or you are just a little bit paranoid,you can use the following script.this is just a workaround to kill all (through register globals) imported vars!if you like it, just drop me a line...greetz subareadot dot dot dot dot alexander at gmail dot com09-Mar-2008 07:19@ Mike Willbanks's postThis is an even cleaner version of your code: $var ){ if( $var === $$key ){ unset($$key); } }}?>oirinel at yahoo dot com18-Dec-2007 12:35when using register_globals=On be careful since using something like:$_SESSION['value'] = 'some value';$value = 'another value';echo $_SESSION['value']; // !!! will print 'another value' !!!!Hope this will save someone from headaches and from loosing hours!Tumasch13-Dec-2007 05:50In addition to Mike Willbanks post:Put this to the beginning of every file or to a functions.inc.php and call it every time before start working with user variables.This will prevent problems with wrong initalized variables or users who try to break your application.And this has an extra bonus: Applications which still work are also register_globasl = off enabled! $int_temp_value) { if (!in_array($int_temp_name, array ( 'GLOBALS', '_FILES', '_REQUEST', '_COOKIE', '_SERVER', '_ENV', '_SESSION', ini_get('session.name'), 'int_temp_name', 'int_temp_value' ))) { unset ($GLOBALS[$int_temp_name]); } }}//// Now, (re)import the variables//if (isset ($_REQUEST['pass'])) $ext_pass = $_REQUEST['pass'];if (isset ($_REQUEST['user'])) $ext_user = $_REQUEST['user'];if (isset ($_REQUEST['action'])) $ext_action = $_REQUEST['action'];//// Cleanup entries//$int_pass = (isset ($ext_pass) ? preg_replace("'[^A-Z]'", "", $ext_pass) : '');$int_user = (isset ($ext_user) ? preg_replace("'[]A-Za-z0-9áäàâãëèéêïìîóöòôõúüùû \.^\$\!\_-()'", "", $ext_user) : '');$int_action = (isset ($ext_action) ? intval($ext_action) : '');//// Import Session variables//if (isset ($_SESSION)) { foreach ($_SESSION as $int_temp_key => $int_temp_value) { if ($int_temp_value != '') { $$int_temp_key = $int_temp_value;
| 0 | 0 | | | |  Ocultando PHPEn general, la seguridad por oscuridad es una de las formas más débiles de seguridad. Pero, en algunos casos, cada pequeño elemento extra de seguridad es deseable.Unas cuantas técnicas simples pueden ayudarle a esconder PHP, posiblemente retrasando a un atacante que esté intentando descubrir debilidades en su sistema. Al establecer expose_php = off en su archivo php.ini, usted reduce la cantidad de información disponible a posibles atacantes.Otra táctica consiste en configurar los servidores web como apache para que procesen diferentes tipos de archivos como scripts de PHP, ya sea con una directiva .htaccess, o en el archivo de configuración de apache mismo. En ese caso puede usar extensiones de archivo que produzcan confusión:Example #1 Ocultando PHP como otro lenguaje# Hacer que el codigo PHP parezca como otro tipo de codigoAddType application/x-httpd-php .asp .py .plU ocultarlo completamente:Example #2 Uso de tipos desconocidos como extensiones para PHP# Hacer que el codigo PHP parezca como de tipos desconocidosAddType application/x-httpd-php .bop .foo .133tO escóndalo como código HTML, lo que tiene un pequeño impacto de rendimiento ya que todos los documentos HTML serán procesados por el motor de PHP:Example #3 Uso de tipos HTML para extensiones PHP# Hacer que todo el codigo PHP luzca como HTMLAddType application/x-httpd-php .htm .htmlPara que esto funcione de manera efectiva, usted debe renombrar sus archivos PHP con las extensiones anteriores. Aunque es una forma de seguridad por oscuridad, representa una medida preventiva menor con pocos inconvenientes.Mantenerse al Día> and for bad URL you can add this code to .htaccess fileof coarse below the first code in .htaccess#--RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^.*$ http://www.example.com/securename [L]prrogers at gmail dot com13-Sep-2007 08:50The default session identifier-name PHPSESSID is publicly visible in an HTTP cookie and or URL if sessions are used. It can be changed in the php.ini to something more generic to further obscure PHP.raven-3 [at] o2 [dot] pl07-Mar-2007 11:23I've found that your script ahmad does not work to me. So I've modified it, maybe someone will find it useful://default page$config['main']="main";//checking query$QS=explode("&",$_SERVER['QUERY_STRING']);$QS=explode('/',$QS[0]);//we have to find out if main page is in Query string//if not, then use defaultif (!$QS[0]) $MODULE=$config['main'];else $MODULE=strtolower($QS[0]);//here everything take place//below query is converted into table.//use it like following: $_QUERY['theme']for ($i=1;$iRewriteEngine OnRewriteBase /RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]then the following simple codemarpetr at NOSPAM dot gmail dot com11-Apr-2006 05:18I think the best way to hide PHP on Apache and Apache itself is this:httpd.conf-------------# ...# Minimize 'Server' header informationServerTokens Prod# Disable server signature on server generated pagesServerSignature Off# ...# Set default file type to PHPDefaultType application/x-httpd-php# ...php.ini------------; ...expose_php = Off; ...Now the URLs will look like this:http://my.server.com/forums/post?forumid=15Now hacker knows only that you are using Apache.ahmad at unikomcenter dot com05-Mar-2006 10:05I am use this script to hidding PHP:index.php--------------we can access the modul in URL like this:=================================www.example.com/?forum/topic/20- it mean load the modul forum.php, and set the _QUERY['topic']=20www.foo.com/?voting/id/54/type/piechart&choice=2- it mean load the modul voting.php, and set the _QUERY['id']=54 and _QUERY['type']='piechart' and set _GET['choice']=2eric at ericwing dot net20-Jan-2006 09:20Something that has not been mentioned here is also the PHPSESSION id that will be displayed in the URL when passing it from page to page using GET. If users have cookies set to off, this will be visible. This can be reset before any session_start() call with ini_set(). Be aware however that this can't be changed in this way if you use autho session start.dyer85 at gmail dot com31-Dec-2005 12:55Although it's probably obvious to most people, Yavuz Darendelioglu's post below utilizes a method that will only work on a *nix OS, not Windows, and probably not Mac.Also, his regex uses some superfluous matching, instead, write the redirect like so: (you don't really need to use absolute path when redirecting to a resource on the same server, either):RedirectMatch (?:awstats|xmlrpc) /deny.php28-Dec-2005 07:29Even you hide your PHP, requests for bugy scripts still come.No matter whether you have the script on your server or not.You can make an additional step for those requests. Since the host now trying that buggy script then, in the future when a new bug arises it will be tried by that host again with a high possibility. So banning that host completey at its first attempt may be a good idea. For this,1- Add Permanent links for those requests in your httpd.conf:RedirectMatch permanent (.*)awstats(.*)$ http://your_server/your_script.htmlRedirectMatch permanent (.*)xmlrpc(.*)$ http://your_server/your_script.htmland add whatever you want to ban.2- Write following code in your_script.htmlYavuz Darendeliogluuser at pampelhuber dot invalid18-Dec-2005 04:32It is unnecessary, to let every Pampelhuber inspect your 'php.ini' files.Put the following into the .htaccess of your htdocuments' root:#Obscure 'php.ini' files (where they exist)RedirectMatch 404 .*php\.ini$jtw9021030-Jun-2005 01:19In order to get the PATH_INFO to work in order to pass parameters using a hidden program/trailing slash/"pretty url" in more recent versions of PHP you MUST add "AcceptPathInfo On" to your httpd.conf.AddType application/x-httpd-php .php .htmlAcceptPathInfo OnTry it out with your phpinfo page and you'll be able to search for PATH_INFO.http://yourserver.com/myphpinfo.php/showmethewayIf you want to drop the .php use one or both of these:DefaultType application/x-httpd-phpForceType application/x-httpd-php25-May-2005 01:06You could also do this in .htaccess when you use Apache and your configuration allows you to override : ForceType application/x-httpd-phpThat way, you can use the URL test?pop=true without having to fake it by using test/index.php.See the Apache manual for more info: http://httpd.apache.org/docs/mod/mod_mime#forcetypebenjamin at sonntag dot fr24-May-2005 09:14In response to the previous messages, for apache, there is a easier way to set files without "." to be executed by PHP, just put this in a ".htaccess" file :DefaultType application/x-httpd-phpdimitar at bastun dot net17-Jan-2005 09:13In case there are an Internal Server error(error 500) using the old code below in an .htaccess file, you can replace it with the code modification that must solve the problem.Old code----------- ForceType application/x-httpd-phpReplacement of the code above(code modification)------------------------------------------------------------AddHandler server-parsed .phpSetHandler application/x-httpd-phpRegards,Dimitar TanevNikolai-Zujev-(at)-Gmail-dot-Com22-Sep-2004 12:22Assign files w/o extension to php interpreterwithout using ReWrite module[clip httpd.conf] ForceType application/x-httpd-php[/clip]php at vfmedia dot de15-Jun-2004 06:21I�ve found an easy way to hide php code and the uri is searchable by google and others...(only for unix or linux)At first I have some rules in my hide.conf (i made an extra .conf for it (apache 2.0))For example when I want to mask the index.php ForceType application/x-httpd-php My problem is, that my code should be readable...so I made an extra folder for example srv/www/htdocs/static_outputMy phpcode is in the includefolder....(for ex. mnt/source/index.php)Then I made a link in the shell > ln mnt/source/index.php srv/www/htdocs/static_output/indexSo the code is readable (with .php extension) in my includefolder and there is only the link in the srv folder without extension(which is called by the browser...).12-May-2004 08:20Keep in mind, if your really freaked out over hiding PHP, GD will expose you.Go ahead - make an image with GD and open with a text editor.. Somewhere in there you'll see a comment with gd & php all over it.php at user dot net10-Apr-2004 06:36What about this in a .htaccess file :RewriteEngine onRewriteRule ^$ /index.php [L]RewriteRule ^([a-zA-Z0-9\-\_/]*)/$ /$1/index.php [L]RewriteRule ^([a-zA-Z0-9\-\_/]*)\.(html|htm)$ /$1.php [L]RewriteRule ^([a-zA-Z0-9\-\_/]*)$ /$1.php [L]Typing "sub.domain.foo/anything" loads "/anything/index.php" if 'anything' is a directory, else it loads "/anything.php".I'm sure you can find mutch better, but it works great on my site :)mmj14-Mar-2004 05:58You can see if somebody's using PHP just by adding the following to the end of the URL:?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000If the page is using PHP, this will show the PHP credits.Setting expose_php to Off in php.ini prevents this.Elora at alexandria dot cc13-Feb-2004 03:30's suggestion won't work. All someone has to do is look at "foo.com/dir/" and try "foo.com/dir/index.html", "foo.com/dir/index.php", "foo.com/dir/index.cgi", until no 403/404 is returned.ldemailly at qualysNOSPAM dot com27-Oct-2003 08:17adding MultiViews to your apache Options configlets you hide/omit .php in the url without any rewriting, etc...l0rdphi1 at liquefyr dot com21-Jul-2003 04:02More fun includes files without file extensions.Simply add that ForceType application/x-httpd-php bit to an Apache .htaccess and you're set.Oh yea, it gets even better when you play with stuff like the following:substr($_SERVER['PATH_INFO'],1);e.g. www.yoursite.com/somepage/55And:foreach ( explode('/',$_SERVER['PATH_INFO']) as $pair ) { list($key,$value) = split('=',$pair,2); $param[$key] = stripslashes($value);}e.g. www.yoursite.com/somepage/param1=value1/param2=value2/etc=etcEnjoy =)Bryce Nesbitt at Obviously.COM27-Mar-2003 08:24Using the .php extension for all your scripts is not necessary, and in fact can be harmful (by exposing too much information about your server, and by limiting what you can do in the future without breaking links). There are several ways to hide your .php script extension:(1) Don't hard code file types at all. Don't specify any dots, and most web servers will automatically find your .php, .html, .pdf, .gif or other matching file. This is called canonical URL format: www.xxxxxx.com/page www.xxxxxx.com/directory/This gives you great flexibility to change your mind in the future, and prevents Windows browsers from making improper assumptions about the file type.(2) In an Apache .htaccess file use: RewriteEngine on RewriteRule page.html page.php(3) Force the webserver to interpret ALL .html files as .php: AddType application/x-httpd-php .php3 .php .htmlbminton at efn dot org27-Feb-2003 12:05Another technique is to have every file be named index.php and be in it's own directory. Then instead of using for instance http://my.site/foo.php you could use http://my.site/foo/ where foo is a directory with a file called index.php in it.29-Jan-2003 10:53PS. If you want to use pretty URLs (i.e. hide your .php extensions) AND you have safe-mode=on, the previous example (ForceType) won't work for you. The problem is that safe-mode forces
| 0 | 0 | |
| ¿Quién está en línea? |  | Nuestros miembros han publicado un total de 23 mensajes
Tenemos 1 miembro registrado.
El último usuario registrado es Admin | En total hay 1 usuario en línea: 0 Registrados, 0 Ocultos y 1 Invitado
El record de usuarios en línea fue de 13 durante el Miér Oct 16, 2024 3:31 am
Usuarios registrados: Ninguno
| | Leyenda : [Administrador ] [ Moderador ] |
 | Nuevos mensajes | | | No hay nuevos mensajes | |  | Foro cerrado |
| |
|
