PHP 8.3 and 8.4

[fraenkiman]

Hi Laborix,

many, many thanks! What I see, we no longer have a problem with setting the server environment variables. I'll go through the errors from the server log and see how to make the affected functions a bit more robust.

Give me a few nights to do this.

Best regards and a good start to the new week
Frank

[fraenkiman]

Hi Laborix,

I have made the affected functions from your comment a bit more robust. You are welcome to send FlatPress 1.4-dev through the penetration parkour again when you get the chance.

With best regards
Frank

[laborix]

Hi Frank,

New run, Penetration quick test, new test results:
Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s)
Server Leaks Version Information via "Server" HTTP Response Header Field
Possible starting points:

Code: Select all

    // http://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder 
    header('X-Frame-Options: SAMEORIGIN');
    header('X-XSS-Protection: 1; mode=block');
    header('X-Content-Type-Options: nosniff');
    // remove PHP version Info
    header_remove("X-Powered-By");
    // End of send header

https://...contact.php - SQL injection may be possible
https://...comments.php - CSFR attack possible in HTML submission form

No verification of inputs, SQL statements, form attacks and so on ...

Interesting, during the setup with PHP 8.4.3 everything went smoothly, the login also worked. After saving the FlatPress configuration (customizing title and so on) FlatPress became slow, then no more clicks possible.
In the log:

Code: Select all

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in ../fpgit1853/fp-includes/core/core.language.php on line 260
PHP Fatal error:  Maximum execution time of 30 seconds exceeded in ../fpgit1853/fp-includes/core/core.cookie.php on line 103
PHP Fatal error:  Maximum execution time of 30 seconds exceeded in ../fpgit1853/fp-includes/core/core.language.php on line 260

After closing the browser and log in again, everything was ok again, including the previously saved configuration. Unfortunately, this could no longer be reproduced (theoretical cache problems?), but I will keep an eye on it.
Ok, new attack run almost no more PHP errors, except for this one:

Code: Select all

PHP Warning:  Undefined array key "user" in ../fpgit1853/fp-content/compile/e93fccb09cf8b04111b9595da102f3f4^f28d0dfa248b74b520244b0130a2b831960aa9fa_0.file.login.tpl.php on line 37

PHP Warning:  strtok(): Both arguments must be provided when starting tokenization in ../fpgit1853/fp-includes/core/core.utils.php on line 104
PHP Warning:  strtok(): Both arguments must be provided when starting tokenization in ../fpgit1853/fp-includes/core/core.utils.php on line 105

I think you've done a great job, the attack factor has decreased significantly (thumb up!)

best regards

[fraenkiman]

Hello Laborix,

thank you for the second run.
I will check if we have SQL injection vulnerability in the contact form. I will also check the comments.php for a possible CSFR vulnerability. I have put everything in an issue here.

Server Leaks Information via “X-Powered-By” HTTP Response Header Field(s)
Server Leaks Version Information via “Server” HTTP Response Header Field

And for this, this issue


Give me a few nights as usual. My little one is sick, so I can only invest a limited amount of time.

Code: Select all

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in ../fpgit1853/fp-includes/core/core.language.php on line 260
PHP Fatal error: Maximum execution time of 30 seconds exceeded in ../fpgit1853/fp-includes/core/core.cookie.php on line 103
PHP Fatal error: Maximum execution time of 30 seconds exceeded in ../fpgit1853/fp-includes/core/core.language.php on line 260

Here shell_exec and session_start are called.
Here I suspect that your test web server is making big cheeks. Do you have the possibility to reproduce this on a more powerful machine with OPcache and APCu? Or completely without cache mechanisms? I have set a timeout for the shell_exec call. This results in the query of the supported locales being aborted after 5 seconds.

Let me/us know if there are any further anomalies.
Relaxing weekend
Frank

[laborix]

... I will check if we have SQL injection vulnerability in the contact form ...

I had been working on the topic of SQL injection for some time and then wrote a string test method for form inputs, search fields and other string inputs.

Code: Select all

   /**
    * Check string for SQL Injection Parameter
    *
    * Debug: 2019-08-23
    * 
    * Basics: https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
    *         https://www.owasp.org/index.php/SQL_Injection_Bypassing_WAF
    *
    * @param     string
    * @return    int returns 0 if the string is unchanged.
    */
   public function test_sql_injection($teststring) {
     
       $replace_count = 0;
     
       $string_orig = 0;
       $string_diff = 0;
     
       $string_orig = strlen($teststring);     
     
       $clean1 = "";
       $clean2 = "";
       $clean3 = "";
     
       $testsql = array(" and ",
                        " AND ",
                        "and ",
                        "AND ",
                        " or ",
                        " OR ",
                        "or ",
                        "OR ",
                        "+or+",
                        "+OR+",
                        "+or+",
                        "+OR+",
                        " 1=1 ",
                        " 1=1",
                        " -- ",
                        "--", 
                        "'", 
                        "‘",
                        "’",
                        " = ",
                        "= ",
                        "NULL",
                        "null",
                        "/");
       $clean1 = str_replace($testsql, " ", $teststring, $replace_count);
       
       $clean2 = str_replace("&&", "&", $clean1, $replace_count);      // OWASP 1 && 1 = 1 -> Alternative Expression of 'or 1 = 1'
       $clean3 = str_replace("||", "|", $clean2, $replace_count);      // OWASP 1 || 1 = 1 -> Alternative Expression of 'or 1 = 1'
       
       $string_diff = strlen($clean3);
             
       if ($string_orig > $string_diff) {
         $replace_count = 1;
       }
             
       return $replace_count;
     
     }

The whole thing can be extended quite a bit, but the hit rate was over 80 percent. Enough for me to recognize attacks

Edit:
A few samples from SQL Injection attacks:

Code: Select all

'case when cast(pg_sleep(15) as varchar) > '' then 0 else 1 end –
case randomblob(10000000) when not null then 1 else 1 end
and 0 in (select sleep(15) ) –
); select “java.lang.Thread.sleep”(15000) from INFORMATION_SCHEMA.SYSTEM_COLUMNS where TABLE_NAME = 'SYSTEM_COLUMNS' and COLUMN_NAME = 'TABLE_NAME' –
“java.lang.Thread.sleep”(15000)
'case when cast(pg_sleep(15.0) as varchar) > '' then 0 else 1 end –

[fraenkiman]

Hello Laborix,

ready for the third run?

I have implemented the following changes in the FlatPress master branch:
- Added CSRF protection for the comment function
- Added CSRF protection for the contact form
- Email header injection protection
- Removed X-Powered-By header
- Adjusted server HTTP header

Fix against:
- PHP Warning: Undefined array key "user"
- PHP Warning: strtok(): Both arguments must be specified at the start of tokenization

I have not been able to find a possible SQL injection vulnerability in the contact form. Checked: contact.php, utils_mail and apply_filters. Here I suspect a false alarm from your penetration suite.

Best regards
Frank

[laborix]

.. ready for the third run? ...
...
I have not been able to find a possible SQL injection vulnerability in the contact form. ...

FlatPress has no SQL injection problem, because FlatPress works without an SQL database in the background.
However, FlatPress does have a problem that SQL injection attacks can be insert in the comments and contact form. Both forms do not check whether an SQL injection action (which is not relevant for FlatPress) is currently being executed.

This week is a bit mixed up, but I will try to find some time for another penetration test

[laborix]

The open penetration test of the current FlatPress 1.4-dev Github 1886 Version has the following results:

Code: Select all

PHP Warning:  strtok(): Both arguments must be provided when starting tokenization in ../fpgit1886/fp-includes/core/core.utils.php on line 110

This is just a single warning, nothing more

So, test or no test, first of all you have done an absolutely outstanding job, there were more than 1,800 attacks and the result is great. You will certainly get the last PHP warning solved, but don't forget to give yourself a break.

Auf Deutsch, vielen Dank für deine hervorragende Arbeit
Viele Grüße

[fraenkiman]

Hollo Laborix,

thank you for the third run. I have replaced strtok() with explode().

With best regards
Frank

[laborix]

Hi,

I maintain the old FlatPress 1.0.3 version for practice. There, the same error appeared in core.utils.php and I threw myself into debugging and retracing the function. After I realized that the error was reproducible, I experimented a bit and found a solution for the attack scenario as well as for the production environment.

The following lines are replaced in the file core.utils.php in function utils_kexplode()

Code: Select all

$k = strtolower(strtok($string, $delim));	
$arr[$k] = strtok($delim);

with this lines

Code: Select all

$k = strtolower(strtok($string, $delim));	        
if (empty($k)) {
  return $arr;
}
    
$arr[$k] = strtok($delim);         
if (empty($arr[$k])) {
  return $arr;
} 

and FlatPress 1.0.3 runs absolutely stable under PHP 8.4.3. It should also work in this constellation with FlatPress 1.4-dev Github 1886.

best regards

ps: It is the original FlatPress 1.0.3 version from June 12, 2015, no extensions, only patches for runnability and I've been maintaining this Version since 2015 just for fun