PHP

Hypertext Preprocessor – PHP

PHP is a three-letter acronym to describe a significant, old language. It is unknown to many on the internet, and what it does is an even more excellent mystery. This blog will explore PHP’s basic concepts, history, security, and surrounding viewpoints.

Introduction to PHP

PHP, a name forming the recursive acronym PHP: Hypertext Preprocessor, is a powerful open-source programming language widely used in web development. It is most commonly used on web servers to process data and access and modify databases. Sometimes it is used in creating dynamic web pages (though not with the same flexibility as JavaScript). Capabilities include form validation, building pages specialized for particular users, and inputting and displaying database contents. It can also manage forums, wikis, and many other things.

What is PHP, and how does it work?

PHP is an open-source language with deep roots in C, Java, and Peril. It is not an actual programming language (like C); instead, it resembles its close cousin, Javascript. It is also considered a scripting language. The code can be embedded into an HTML page with relative simplicity.

It must utilize a processor, as it cannot load and process data. This is due to its inherent nature of not being an actual coding language. In other words, this language must be run on “PHP enabled” computers. Also, its roots and design are based on the syntax of multiple languages. As with most languages, It has undergone many revisions throughout its lifetime.

PHP Server

PHP pages are run server-side, and what is generated based on a set of circumstances is delivered to the user. A PHP server works similarly to one that runs regular HTML/CSS. However, there is a crucial difference between running a web page with the file extension .php instead of .html. A page built with PHP goes through a special processor that interprets, compiles, and displays data to the user. In simpler terms, it is one extra step to loading a page.

Javascript can be easily edited, even by accident, by the most computer-illiterate user. For example, a login form is created via a server-side scripting language instead of Javascript. This is because a page created in Javascript would display all the validation code that keeps hackers out. A raw HTML and Javascript page sends the page and all the code to the user immediately.

Manipulating Server-side Scripting

The server-side scripting language cannot be manipulated by the user straight from the website source if coded correctly. While there are ways to trick this language, it’s inherently more secure than Javascript. Users of the page can’t see what is happening behind the scenes. All they see is what is laid out in front of them. Hence, a login page is less likely to be hacked through direct modification.

Not always a .php extension

The file extension for a PHP file does not have to be .php. It can be .phtml or any other extension set in the web server’s configuration. Additionally, the ugly .php file extension (or whatever file extension you use) does not need to be shown. Proper server configuration can see it vanish entirely.

Well-configured pages can show example.com/login instead of example.com/login.php?gibberishcodehere if they wish. Websites like the Google Accounts login service don’t mask content in the title bar. This can make for a messy title bar.

This server-side scripting language is not universal! While most popular web servers support it, everyone does not support it. ASP.NET is a potent competitor. It enjoys widespread support but faces competition from other sources, such as Microsoft’s open-source ASP.NET framework. W3schools.com, for example, makes heavy use of ASP in its pages over this server-side language.

History of PHP

PHP has had many names, and it is in its beginnings that it has had the most names. This server-side scripting language was initially designed by a developer called Rasmus Lerdorf in 1994 to track visits to his online resume. It was originally called “Personal Home Page Tools,” aka “PHP Tools,” when opened for public use.

PHP became popular, driving Ramses to revise the original code to include database interaction and more user capabilities to create actual applications (such as guestbooks). In 1995, the source code was released to be used by developers. This allowed the community to detect and fix website bugs that arose as it grew. At the time, it was not a pretty whole language. It was designed for Unix systems, not Windows.

Late that year, Ramses revised PHP again and renamed it “FI” (Forms Interpreter), named such due to the fancy new features it contained. The variables were “Perl-like” and quite dynamic for their time. Some of them, including the variable syntax and embedded HTML functions, are still used today. However, there was one interesting quirk about this revision. To embed it, the code had to be placed in HTML comments. Naturally, that wasn’t the most popular decision.

Introducing the Personal Home Page

Despite the strange placement of code, PHP (or FI at the time) continued to grow and become more widespread. Ramses rebuilt the code from the ground up to allow C and Perl developers easy access. He brought the PHP name back, with PHP now meaning “Personal Home Page Construction Kit.”

It was the first compelling release that could expand beyond being hosted on Unix. While it grew by leaps and bounds, it wasn’t a whole language. Its proverbial eyes were set on Windows NT. Finally, it was powerful and relevant enough to give it a shot.

PHP entered as a Programming Language in 1996

This programming language achieved its dream in 1996 and became an actual language under PHP/FI – PHP 2.0. It included advanced features such as built-in support for popular databases, cookies, and user-defined functions. Again, tools are in widespread use today. However, its era was short-lived. While popularity rose after its release, it was swiftly rebuilt and replaced after leaving beta status in 1997. By then, it was present on thousands of domains.

In late 1997, PHP was still primarily the work of a single developer. Two developers, Andi Gutmans and ZeevSuraski, required more features to complete an eCommerce application. They began to rewrite the processor and create something new entirely alongside Rasmus.

The 3.0 version rose not long after PHP 2 left beta. The language was renamed to its modern name, PHP: Hypertext Preprocessor. The primary appeal of this version was its flexibility – it allowed extensions that went far beyond its base code. It also included object-oriented programming support and a more organized language structure. It became 2.0’s official successor in 1998.

70,000 Domains

With PHP 4, PHP had expanded beyond 70,000 domains and was widespread on windows servers. It was mighty and widely used. However, PHP 3 lasted only until mid-1999. Gutmans and Suraski rewrite the base code again to improve PHP’s competence with complex programs. 3.0 was powerful but not powerful enough to approach projects on a massive scale. 4.0 was released as complete by 2000, and many new features, including far superior performance.

Years passed; PHP seemed to reach the peak of its development. PHP 5 was released in 2004 to include slightly revised and brand-new features. This was then updated for a long time until PHP 7 came out recently. Overall, the development of PHP did not include massive rewrites of the base code again. The development team is now dozens of developers larger than the three-person team in the past.

PHP Security

This language is arguably easy to use but becomes a new beast when looking at security. This is caused by insufficient validation and unrestricted access to table data. Namely, there are ways for users to place actual code statements into forms, followed by having those statements pull out data that shouldn’t have been accessed. The motives for doing this are vast, and the means are relatively common.

One of the most significant issues is unvalidated input from users. Sitepoint suggests that a PHP developer treats every user who accesses the web form as a potential threat. Some users attempt to put gibberish into forms and submit them for fun. The key idea is never to trust user input, even those who aren’t actively trying to hack the system.

The issue above causes many others that are known in PHP. A user’s session ID should be protected as best as possible. While it is impossible to cover them completely, minimizing the possibility of a compromised ID is a good idea.

A compromised session ID on a forum means that a regular user could pose as an admin. The potential issues of that should be rather plain. XSS (cross-site scripting) attacks mean that code such as JavaScript is placed into a form, then run by the server. If not correctly validated, the code runs to do whatever the hacker desires, typically not to benefit other site users.

Access Flaws

Sometimes lying slightly outside of regular PHP yet critical for PHP developers, one common issue is access flaws. An access flaw is when users can enter directories or pages they’ve no right to. A compromised session ID has been noted above.

A policy for proper access must be maintained at all times. Important information should never be set in a directory visible on the web. Part of this does lie directly with the PHP developer. Some forms allow users to enter a page and then go to it. The syntax ../ means to go up one directory. Using poor PHP code, a person could use ../ to navigate outside the web directory. That could move into, say, the host operating system files.

One effective counter to this is using an unpredictable directory structure. For example, host PC/twwir/wbthing/host/sitecontents/ instead of hostpc/host/sitecontents/. Then again, the most effective counter is to have the right policies in place so that this does not happen at all.

While it may seem paranoid, a PHP developer should always anticipate users attempting to break the system. PHP is powerful and very secure in the right hands. It is useless when it lets an angered former employee delete System32.

What’s Wrong with this Server Side Language?

Perhaps a strange title, but this should be noted as this blog draws close. Reasons cited for hating PHP include rampant vulnerabilities, terrible syntax, insecure code policies, and poor documentation. Others are inconsistent coding and the frequency of terrible PHP coders. One source states, “PHP” references will damage your brain”…

To be fair – yes, this language is a bit quirky. There are redundant pieces (Two built-in functions, “exit” and “die,” do virtually the same thing). There are parts here and there that don’t work logically. And prior revisions have been built on compressing many functions into a single location and making them work. Some of the aforementioned “problems with PHP,” such as terrible coders, can be fixed simply by learning this language properly.

Yes, it is effortless to make insecure code. A coder must learn to know and check every point that can go wrong. Otherwise, something will inevitably go wrong. It is simple enough to code insecurely. It’s quite another matter to make it (almost) completely secure.

Summary of PHP

You’ve read a lot about this server-side scripting language, and this page didn’t even cover specific coding examples. There is so much to know about PHP; it must be exceptionally well-known to use it properly. One could argue it is a simpler language to pick up and a great web development software language and tool for web developers. The core syntax is relatively simple, and PHP is more than just coding the application and creating secure web pages.