Today (23rd of November), PHP 8.3 was released. It brings many enhancements and speed improvements. As PHsPeed, we have been working with PHP 8.3 since the first Release candidate, and so far, we have found no issues in our run-time modules, which is good news.

However, we cannot release the support for PHP 8.3 by PHsPeed, although it is fully ready in our development environment. The main reason is that XDebug, the tool that we use in our debugger, is still in the Alpha release. Although it works like a charm, we still consider this a risk, and as a basic principle, we do not want to release PHsPeed versions with tools that do not have a production status and are still in Alpha. For your development, it has no consequences as you can develop under PHP 8.2 and migrate when PHP 8.3 becomes available.

Users of SQL Server need to wait anyway because Microsoft hasn't released their PDO drivers for PHP 8.3 yet. I hope they will release them soon, but it took a couple of months before they released the drivers for PHP 8.2, and it may take a similar amount of time.

Due to changes in XDebug, we had to make some changes in PHsPeed to fix compatibility issues.

The first issue is that the application will generate obscure errors when you start a program in normal mode while XDebug is loaded. We fixed that by loading php.ini, depending on the status. This does take a bit of time as Apache needs to shut down, php.ini copied, and Apache restarted.

Another issue (not XDebug related) is that sometimes PHP files are locked by Apache when you are debugging and closing the debugger. We fixed that by restarting Apache when you run the application.

Finally, there is a DLL conflict between the XDebug environment and Apache environment. They both use a DLL, but of different versions. We have fixed this by changing the Apache environment.

Of course, when we release the next version of PHsPeed, there will also be a lot of improvements, fixes, and enhancements. The list (so far, and not complete).

 - support for PHP 8.3
 - upgraded XDebug
 - upgraded Summernote
 - upgraded JQuery
 - support for dblabel in form generator
 - setting for not-editable form (results in dblabel fields)
 - improved several hints
 - added a button to refresh database connection properties from the db config
 - free html formatted field
 - on creating events, additional remarks are added as an extra guide
 - when selecting an event, the use is also displayed in the property editor
 - if a cdbgrid is used in a module, then user buttons are now supported
 - you can now test your application containing cloudconnector(s) with the application parameters option
 - new property columnwidth for dbtable columns
 - edited record now stay in focus.
 - the rownumber is not reset to 0 after update but rewound to the original.
 - support for multi-step form
 - New lanes component for creating kanban like boards (replacing the current implementation)

// fixes
 - setting dbfields visible/invisible is fixed (could not unset invisible)
 - label pdevtools removed (annoying label with no purpose)
 - bulk edit now accepts label fields
 - label behaves as any input field.
 - snippet code generator simplequery quote fix and improved to only use field in where
 - template component now supports all predefined modes.
 - reimplemented a move of rows/columns to avoid the original issue that sometimes the changes revert.
 - Data structure treeview corrected for the situation that refreshing the tree could caused stacking
 - Required on dropdown is now working
 - Custom fields in DBTable could corrupt insert and update statements.
 - Webserver is reset before run, fixes issues with files being locked while debugging.

PHsPeed is continuously working to improve the product, and we also have great plans for the following releases. But we're always open for good ideas. So if you have remarks, ideas, and even complaints, please let us know.

Happy coding!

We got some questions about the features that will become available in version 3.1. And as we can imagine that most of our users want to know, we will start by making posts about the features available in this upcoming version. But not before I have said a big thanks to all of you for your input, wishes, requests, remarks, and mostly positive feedback. It is highly appreciated! We try hard to keep up and to perform the best in our response to you. We honestly believe that it is not the art of finding new customers but keeping your current. Too many companies focus on finding new customers and forget their current user pool when the current users should be the ambassador for your product. And to appreciate your work, we have a bounty program. If you are a customer of PHsPeed with a license that is at least 6 months old, then you will get two months free for each customer you bring in.

But what about 3.1?

First of all, and as usual, we fixed a few issues.

• The tabs in the IDE could be moved with the mouse, while the content stayed the same, causing wrong labels above the tabs. Not something most of you will have noticed, but it was there and is fixed.
• A more serious one was an obscure error that caused some kind of infinite loop in certain Master-detail relationships. The screen kept refreshing. This one is fixed, and the customers reporting them already have a hotfix available.
• Sometimes annoying, setting and releasing breakpoints during a debug session was not applied immediately. That is corrected.

Most of the fixed issues can be found in our bug tracker. Yes, I know. It doesn't look fine while we are on PHP 8.1. But we will replace the FireSpray bug tracker with a PHsPeed build version soon. And the good news is, it will also be available for our customers as a sample application.

Then the new features, and we're excited to share these. I will not go into detail yet but will do it in the following posts.

• Support for conditional breakpoints. This will allow to add an expression to the breakpoint that will fire if the condition is true. Very useful for developers.
• Support for UUID datatype. This datatype is a unique identifier currently supported by more databases that we can no longer ignore. For MySQL / MariaDB users: this datatype is only supported in the latest versions of MariaDB. For MySQL, the datatype remains varchar.
• Last-minute ddl extraction. In environments where there are a huge number of tables, retrieving metadata could have a very slow response. To improve, PHsPeed will only retrieve table info when required. Tables not in use will not be touched, which improves the responsiveness hugely.
• Cosmetic but highly requested: rounded input fields are now supported.
• Also highly requested: PHsPeed will now only include javascript and css files that are in use, depending on the components that you have put on the form.
• Code snippets for creating a simple query or email. This will reduce development time because you don't have to look up syntax and properties. Just enter a few parameters, and PHsPeed will generate the code. This feature will be enhanced over the upcoming versions.
• If you use the refined search option, then you will be able to add a hide/show button.
• DBnav button properties can now be changed in the events. Change the label and color on the fly.
• It is now possible to apply for flooding protection. Someone flooding your login page will end up in the ban list after a configurable amount of attempts.
• The label component now behaves like all the other components, which means it will follow the form rules of label positioning.
• The code completion is enhanced with the object methods.
• You can now use forms in a master-detail relationship.
• On large projects, it is handy to group modules together. This module to organise your project is improved.
• Debug run when you require a setup of globals can now be set as program parameters.
• The CSS editor is simplified.

I can imagine that some of these items are a bit unclear. But in the next weeks, we will go over the enhancements. The current status is that we are finishing some of the features before we will start with our alpha testing.

Happy coding!

The short answer is yes, but the real question is, is that enough? After all, you, as a developer, create software with the help of our tool and add your code, so eventually, the absolute safety of the application is a combination of both. PHsPeed has a lot of protection built in. There are several tokens, like CSRF, and there is protection against XSS and SQL injection. We try to keep up with the libraries we use to avoid introducing vulnerabilities.

Automated vulnerability tools of commercial parties can scan your website. Some parties can scan your code, and you pay per line of code. That makes it quite expensive, and it never replaces the work of a real ethical hacker. But there are ways that you can use to verify the created project for vulnerabilities, and I like to show you the results of ZAP, an open source and free tool from the OWASP community. This tool is able to scan your project and I will explain the result of one of our applications here.

This is the customer portal that you find on our website. In the next screenshot you see the result of a ZAP scan:

If you want to do something similar then download ZAP from the OWASP website, and use localhost:8010/your application to scan. So what does the scan tell us?

There are 18 notifications. So let's look into them one by one:

• The first message complains about the absence of a CSRF token.
  This is a false positive message as PHsPeed does use a CSRF token, but ZAP does not recognize it. You can easily verify this by not touching your application for 10 minutes and then trying to continue. You will get a csrf error message. You will find the code in your main application: NoCSRF::check('main_csrf', $_POST, true, 60*10, false ); // 10 minutes one-time mode 
  
  
• Application error disclosure
  This notification tells us that we display errors when they occur in the code. That is a severe issue when the application is in production. You do not want error messages to appear when the application crashes for any reason. PHsPeed requires you to promote your code so that all debugging info is removed from your production code. But while developing, you want the messages because you need to be able to debug. So this warning is of no meaning here, but is, when you have this in your production environment.
  
  
• CSP wildcard directive
  Content Security Policy (CSP) is an added security layer that helps detect and mitigate certain types of attacks. Including (but not limited to) Cross-Site Scripting (XSS), and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP provides a set of standard HTTP headers that allow website owners to declare approved sources of content that browsers should be allowed to load on that page — covered types are JavaScript, CSS, HTML frames, fonts, images, and embeddable objects such as Java applets, ActiveX, audio and video files. This must be configured on the web server, which is not the case in our development environment. But PHsPeed does generate code to force this in the html meta code.
  
  
• Content Security Policy (CSP) Header Not Set (5)
  This is similar to the message above.
  
  
• Hidden File Found (2)
  We have a Xampp environment set up for development, NOT production. The two hidden functions are server-info and server-status, used for debugging. But in your production environment, this should be configured out, as you never should give information about your environment to (potential) hackers.
  
  
• Missing Anti-clickjacking Header (2)
  This message applies to a missing setting in relation to IFrames. PHsPeed does not use IFrames.
  
  
• Missing Anti-clickjacking Header (2)
  This is a message that you should take very seriously, and it refers to outdated libraries. We have upgraded the libraries already, but this is a good showcase of an issue you might find. If you open the item, you will see which library(s) needs updating.
  
  
• Cookie No HttpOnly Flag
  This flag is forced in the generated PHP code (when you have configured that in the project options), but it depends on your installation if this setting applies or not. For development, this is not an issue, but in production, you need to see what your provider can do (as it can be set in php.ini, on the web server, or with the provided code below if the function is enabled).
  
  if(session_set_cookie_params([
  'path' => '/',
  'domain' => 'localhost',
  'httponly' => true,
  'samesite' => 'Strict',
  'lifetime' => 3600
  ])==false ){
  die('failed to set cookie parameters');
  }
  
  
• Cookie without SameSite Attribute
  See above.
  
  
• Cross-Domain JavaScript Source File Inclusion (2)
  This message refers to a javascript library imported from an external website. In this case, Google. PHsPeed uses internal libraries by default (which is advised by OWASP) and avoids importing them, although you can choose to do so in the preferences. But some libraries cannot be stored locally.
  
  
• Information Disclosure - Debug Error Messages (2)
  This is the same as described under 'Application error disclosure.'
  
  
• Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s) (2)
  It should be disabled on the web server level. For our development environment, this is not an issue.
  
  
• Server Leaks Version Information via "Server" HTTP Response Header Field (38)
  It should be disabled on the web server level. For our development environment, this is not an issue.
  
  
• X-Content-Type-Options Header Missing (34)
  For mimed information, you can set a sniffing parameter. It is a low-risk item and not commonly used (yet)
  
  
• Information Disclosure - Suspicious Comments (12)
  This report gives information about static texts in your (javascript) code. It does on every string like: module&&module.exports?module.exports=b(require("jquery")):" where it triggers on 'jquery'. Although it is good to verify all the reported items, it is usually not an issue.
  
  
• Loosely Scoped Cookie (67)
  Cookies can be scoped by domain or path. This check is only concerned with domain scope. The domain scope applied to a cookie determines which domains can access it. For example, a cookie can be scoped strictly to a subdomain, e.g., www.nottrusted.com, or loosely scoped to a parent domain, e.g., nottrusted.com. In the latter case, any subdomain of nottrusted.com can access the cookie. Loosely scoped cookies are standard in mega-applications like google.com and live.com. Cookies set from a subdomain like app.foo.bar are transmitted only to that domain by the browser. However, cookies scoped to a parent-level domain may be transmitted to the parent or any subdomain of the parent.
  
  
• Modern Web Application (2)
  This is an informational alert, so no changes are required. No links have been found while there are scripts, which is an indication that this is a modern web application.
  Good to know that we have created something that is considered to be modern ;-)
  
  
• User Agent Fuzzer (12)
  Check for differences in response based on fuzzed User Agent (e.g. mobile sites, access as a Search Engine Crawler). Compares the response status code and the hashcode of the response body with the original response. Actually not an alert either.
  
  

Conclusion. The application we tested has no High-risk items, a few medium risks (due to the fact that the web server used is configured for development and testing and a library with a newer version), and a few low-risk items. Considering the result, updating the libraries fixes all issues here.

The main question is now, is the application safe? Well, to a certain extent. No application is 100% safe, and this is an automated test. It is helpful, but an actual penetration test by an ethical hacker is always advised, especially if you manage critical data. But it is obvious that we do our checks often and are continuously aware of threats. But in the end, you, as a user, are creating applications. Therefore you have your own responsibility to verify the quality of the result. No 2 applications will be the same; therefore, ALWAYS do your own testing! If you have vulnerabilities that you believe are the result of some mishap in our code, report these, and we will do our utmost best to fix them with #1 priority.

Happy coding!