Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 0 articles for you...
102
network securityweb applicationphp securityEnhance PHP Security: Best Practices and Mitigation Strategies
Organizations classify Hypertext Preprocessors (PHPs) as the most popular programming language since some of the biggest Internet names use the service in their businesses. PHPs help companies build websites, create applications, and manage their systems. . Although PHP is a powerful language that permits companies to explore their online potential, PHP is not the most secure option available, leaving organizations at risk of cloud security breaches, attacks, and other issues that could destroy a business’s reputation. Fortunately, there are solutions you can implement to strengthen your PHPs against any network security threat. This article will explain PHP’s relevance today, application pentesting , and best practices to utilize when mitigating attacks. How Do Companies Use PHP for Security? Is It Still Relevant? PHPs can still be helpful in security, as they can be relevant when appropriately used to determine what risks you might have in your system. Companies identify cybersecurity vulnerabilities using application pentesting software to simulate attacks in network security through the system. This type of privacy sandboxing can find flaws in company coding that could permit threat actors to take over websites and compromise sensitive data. This solution can find insecure coding, misconfigured settings, broken authentication controls, and information leaks. You can mitigate data and network security issues straightaway when using PHPs to combat hackers. If you're planning to hire dedicated PHP developer teams, ensure they follow these secure coding practices. What Insecurities Do PHP Web Applications Have? Some PHPs have Content Management Systems (CMS) built into the server as an extra level of protection in your system. To strengthen a company, PHPs implement CMS options like WordPress, Joomla, Magento, and Drupal. However, these services sometimes harbor cybersecurity vulnerabilities that allow cybercriminals to bypass security when you use this product. WordPress has networksecurity issues that have increased vulnerabilities from seventy-four to eighty-three percent in just about a year. Fortunately, organizations consistently seek to improve the security posture options they provide to users to ensure they are safe to utilize for users. How Can Application Pentesting Benefit Businesses? As the name suggests, application pentesting focuses on identifying cybersecurity vulnerabilities in your web applications by inspecting your server for necessary patching in cybersecurity. Pentesting can find flaws in coding that could permit attackers to breach your system and steal credentials or data. With this privacy sandboxing technique, you can learn about misconfigurations, broken authentications, access control weaknesses, information leaks, and more within your company. Once you know the risk, you can remediate these exploits in cybersecurity before threat actors get their hands on them. What PHP Best Practices Should I Employ to Strengthen Security? 1. Always use the latest version of PHP Use the latest PHP version since it will be up-to-date with the latest security news so your company can have the features it needs to strengthen online security. 2. Properly configure the PHP.ini file and other requisites Here is how you can tailor your system to your needs by starting with these configurations: session.save_path session.cookie_path (e.g. /var/www/mysite) session.cookie_domain After configuring those settings properly, there are a couple other settings you can edit to keep your PHP application secure. Let's take a look at the checklist below: expose_php = Off This restricts the disclosure of PHP version from being sent in HTTP Headers. When enabled, expose_php tells everyone that PHP is installed on that specific server or system, which includes the PHP version within the HTTP header, e.g (Powered by: PHP/8.1.2). You can do this for any system and works well if you are using nginx. allow_url_include=Off Setting thisto off prevents remote code execution attacks. display_errors = Off This displays whether errors should be printed on the screen to everyone visiting the site. This should be disabled as a best security practice. session.cookie_httponly = 1 Setting this to 1 disables access to cookies via Javascript APIs but use this with caution as you could break something session.use_strict_mode = 1 Setting this to 1 prevents session fixation attacks session.cookie_secure = 1 This requires cookies to strictly transmitted over HTTPS only session.cookie_samesite = Strict Setting this to strict prevents cross-origin attacks session.use_trans_sid = 0 This is not needed so set it to zero session.sid_length = 128 Here, we are setting the length of the session string which prevents brute force attacks session.sid_bits_per_character = 6 This increases the randomness of the session string which also prevents brute force attack file_uploads=off Here, we are disabling file uploads. If anyone needs to upload files, you can set a limit on the size of the files by doing upload_max_filesize = 1M 3. Use up-to-date code dependencies and third-party components, and update your web server! Update your web server to implement up-to-date code dependencies and third-party components, so your cloud security frameworks utilize newly obtained knowledge to prevent exploits in cybersecurity vulnerabilities. If you use Apache Web Server, keep it updated, turn on error logging, add firewalls, set HTTP limits, and only stay active modules. Install mod_evasive, which will maintain running servers even when attacked. An SSL certificate can provide data and network security in online communication. 4. Do not store passwords using reversible encryption Avoid storing passwords with reversible encryption that attackers can easily crack and decrypt for attackers to spy on and track youractivities. Hackers can also enumerate all other passwords if you have a static decryption key. Hash passwords with algorithms like bcrypt, AES, Open SSL, and Argon2. These options are less vulnerable to attacks in network security, making them better password-storing options that will protect your server from data theft issues. 5. Don’t rely on cookies for security Encrypt cookies before relying on them for security since cookies cannot protect login credentials and sensitive data alone. Use network security toolkits like Halite (by Libsodium), OpenSSL, or AES 256-bit with CBC mode encryption to prevent hacking. 6. Validate user input Only process PHP codes once you validate the user input so PHPs can verify forms, URL parameters, and JSON payloads with filter_var() options like the one below. Utilize this coding to prevent Cross-Site Scripting (XSS) and other malicious attacks. function is_valid_email($email = "") { return filter_var(trim($email), FILTER_VALIDATE_EMAIL); } 7. Perform regular security audits Perform web and cloud security audits to identify web application security vulnerabilities so you can utilize security patching to fix them before an attack. Such audits can improve response times and provide more reliable application performances. These web and cloud security scanners can check for Cross-Site Scripting Vulnerabilities (XSS), Cross-Site Request Forgery Vulnerabilities (CSRF), SQL Injections, PHP Code Injection, Cookie Denial of Service Attacks, and Timing Attacks. 8. Use PHP Libraries Use PHP Libraries so your developers can secure applications better for functionality. Consider the following coding options for preparing your server. Final Thoughts on PHP Security Having a PHP in your server is vital to ensuring robust data and network security. Threat actors like to take advantage of exploits in cybersecurity left behind by poor configurations,so be sure to follow the best php cybersecurity practices we discussed here so you can improve your security posture. Regularly perform web and cloud security audits to identify PHP security issues before they become a substantial risk. Incorporating AI-driven security strategies are becoming increasingly important in the proactive identification and mitigation of sophisticated cyber threats, which PHP applications may also need to consider in their ever-evolving security protocols. . Strengthen PHP applications against network security threats with best practices, pentesting solutions, and expert tips.. organizations, classify, hypertext, preprocessors, (phps), popular, programming, language, since. . Brian Gomez
May 09, 2023
•
102
php securityweb serverbest practicesEffective Strategies to Secure PHP on Linux Web Servers for Safety
Running PHP on a Linux web server is a prerequisite for the use of many popular applications such as Wordpress, Joomla and Drupal. Linux administrators and web developers must approach PHP with caution, as new vulnerabilities in poorly written and implemented PHP code are abundant and dangerous. . In a recent security incident, hackers were able to add a backdoor to the PHP source code . Although the backdoor mechanism was discovered before it made it into production, the incident serves as the latest reminder of the importance of prioritizing PHP security. PHP security is inextricably tied to web server security. Because the popular open-source server-side scripting language is often paired with MySQL, PHP compromise can mean a compromise of the accompanying MySQL database, as well as any web applications running on the web server. This article will examine how you can configure and run PHP securely to mitigate the risk of attacks and compromise, secure web applications, protect user privacy and maintain a secure and properly functioning Linux web server. PHP Vulnerabilities Carry Great Risk for Admins Vulnerabilities in PHP code are a prevalent and serious threat to web server administrators and web application developers. These flaws are often introduced when developers are writing code, either due to a mistake or the inability to anticipate malicious hackers’ ever-evolving techniques. A plethora of vulnerabilities exist in the PHP core - with new security bugs being discovered each month. On March 28, 2021, hackers breached the internal PHP Git repository and inserted a backdoor into the PHP source code. Luckily, the malicious code was discovered by Michael Voříšek before it made it into production, and the hack led the PHP team to move source code management operations from its internal Git server to its official GitHub account, which will serve as PHP’s official Git repository going forward. In another PHP security incident that occurred less than three years ago and has yetto be explained today, hackers compromised the official PHP PEAR extensions system website and hosted a backdoored version of the PHP PEAR package manager for almost six months. PHP vulnerabilities can be exploited by attackers to spread malware & take control of hundreds of thousands of web servers in botnets. In one such instance this past year, the infamous hackers-for-hire group DarkCrewFriends resurfaced with a dangerous botnet strategy exploiting an unrestricted file upload vulnerability to compromise PHP servers running websites. In another malicious campaign a year prior, the Neutrino botnet was discovered hijacking servers by taking over other hackers’ PHP and Java web shells to install a cryptocurrency-mining malware . To help you better understand the threats that your web servers and web applications face, let’s take a look at some of the most notorious types of PHP vulnerabilities. A Quick Look at the Most Common & Dangerous Types of PHP Vulnerabilities Threatening Your Web Servers Remote Code Execution (RCE) In this type of vulnerability, a bug in a PHP application accepts user input and evaluates it as PHP code, enabling an attacker to upload code to a website and execute it. This could, for example, allow a malicious actor to tell the website to create a new file containing code that gives him or her full access to the compromised website. RCE vulnerabilities are very serious because they are easy to exploit and grant an attacker full access when exploited. SQL Injection (SQLi) SQL injection (SQLi) occurs when a hacker is able to send instructions to a database and the database executes those instructions. This type of vulnerability occurs when a PHP developer takes input from a website visitor and passes it to the database without reviewing it for malicious code. SQLi vulnerabilities are very serious because they are easy to exploit and often grant full access immediately. Cross-Site Scripting (XSS) Cross-site scripting (XSS) takes place when an attacker causesmalicious code to load in a website visitor’s browser and execute. This code often steals user cookies to grant the attacker administrative level access or performs functions as the user to grant additional access. Cross-site Request Forgery (CSRF) Cross-site request forgery (CSRF) describes a scenario in which a user is tricked into issuing a request that is not in his or her best interest. For instance, an attacker may create a link and trick an administrator into clicking on that link, causing the site to take a certain action such as creating a new ‘admin’ user with a known password. This critical WordPress vulnerability which was fixed in November of 2020 left servers vulnerable to a variety of attacks including cross-site request forgery and cross-site scripting. Authentication Bypass This type of vulnerability is introduced through incorrect validation that a site visitor has the access level required to take a certain action. For example, a developer may wrongly use a function called ‘is_admin()’ - which is designed to indicate if someone is viewing an admin page - to try to validate that someone is an administrator, mistakenly granting non-admin users access to features that only administrators should have access to. PHP Object Injection PHP object injection is a complex attack that occurs when a PHP application takes user input and passes it to the unserialize() function, which takes a stored object and turns it into an object in memory. This type of vulnerability occurs when a developer allows user input to be used in an unsafe way within a PHP application. The unserialize() function must be approached with extreme caution, as this function is commonly exploited by attackers. PHP 7 has includes a new filtered unserialize feature designed to mitigate the impact of code injection vulnerabilities by requiring that developers specify classes that are safe to unserialize. However, it is critical to keep in mind that even with this improvement, passing untrusted input tounserialize() is never safe. Remote File Inclusion (RFI) & Local File Inclusion (LFI) Remote file inclusion (RFI) and local file inclusion (LFI) take place when a PHP application takes user input and passes it to a function designed to load a file. The inclusion of a remote file in a URL is known as Remote File Inclusion (RFI) while the inclusion of a local file in a URL is known as Local File Inclusion (LFI). LFI is often the method an attacker employs to gain access to a WordPress website’s wp-config.php file. Source Code Revelation This type of vulnerability has to do with people being able to see the names and content of files that they shouldn’t be able to view due to the breakdown of a web server’s configuration. The code revealed in this type of vulnerability may list accessible configuration files or contain sensitive information such as database credentials. Session Hijacking Session hijacking occurs when a malicious actor steals a user’s session ID. When a session is set up between a client and a web server, PHP will store the session ID in a cookie on the client side. Sending the ID with the page request provides access to this confidential information, potentially resulting in session hijacking. Session IDs are commonly stolen via XSS attacks, and can also be vulnerable server-side through the use of hosting services that store session information in globally accessible directories. These vulnerabilities in Apache versions 2.4.33-1 and prior - which have since been fixed upstream - left web servers susceptible to session hijacking and an array of other dangerous exploits. Directory Traversal Directory traversal looks for vulnerable websites and causes files to be accessed that the owner did not plan on making publicly accessible. It is also referred to as the ../ (dot, dot, slash) attack, the climbing attack, or the backtracking attack. Tracking advisories is critical in preventing all of these prevalent and serious types of PHP vulnerabilities. Subscribing to ourweekly Linux Advisory Watch newsletter is an easy, convenient way to stay up-to-date on the latest advisories and updates issues by your Linux distro. In addition to tracking advisories, we recommend that web server administrators implement the ModSecurity web application firewall (WAF), which can provide another line of defense against the attacks listed above. The open-source, cross platform WAF has a robust event-based programming language and allows for HTTP traffic monitoring, logging and real-time analysis. Best Practices for Improving PHP Security The majority of attacks on Linux web servers can be attributed to misconfigurations and poor administration. Thus, it is essential that administrators configure their web servers to be as secure as is practical within the construct of their environment. The Open Web Application Security Project (OWASP) , a nonprofit fo undation we trust and admire that works to improve the security of software through community-led open-source projects, suggests that administrators and developers implement these secure PHP configuration recommendations to protect their web servers against dangerous PHP vulnerabilities and prevent attacks. LinuxSecurity.com PHP security experts Brittany Day and Dave Wreski have additional tips and advice for improving PHP security, which we will explore in this section. Our Top PHP Security Tips & Advice Update Your PHP Version and Modules Regularly It is critically important that administrators and developers update their PHP version and modules regularly. With the support of the open-source community behind PHP, patches and bug fixes for vulnerabilities are released frequently, and newer versions of PHP and its modules often contain mitigations for known security issues that can be exploited by malicious hackers. As of January, 2022, the stable release for PHP is version 8.1.1 , from December 2021. It should be noted that when PHP is being used in a hosting environment, users may not be able to update their PHPversion number. In such scenarios, users must be especially careful and vigilant. They should also explore potential workarounds and demand that their hosting provider update PHP at the earliest opportunity. Restrict PHP Information Leakage The unfortunate reality is that it is common for platforms to leak sensitive information - and PHP is no exception. For example, PHP releases versions and the fact that it is installed on a server through the expose_php directive. To prevent the leakage of this sensitive data, administrators should set this directive to off in /etc/php.d/security.ini. expose_php=Off Control File System Access PHP can access files by default via the open_basedir directive using functions like fopen(). To control file access and prevent security issues, the open_basedir directive should always be set to the /var/www/html directory. open_basedir="/var/www/html/" Disable Remote Code Execution (RCE) In PHP, remote code execution is enabled by default. The "allow_url_fopen" directive allows functions including require, include, or URL-aware fopen wrappers to obtain direct access to PHP files. Remote access can be obtained using the HTTP and FTP protocols, leaving system defenseless against code injection vulnerabilities. To protect against these types of exploits, administrators should disable remote code execution by setting the "allow_url_fopen" directive to "Off". Disable Dangerous PHP Functions & Get Rid of Unnecessary Modules PHP comes with a selection of useful functions, but is also plagued with functions that can be exploited by attackers and should be disabled. To disable these dangerous functions, administrators must edit the php.ini file. In this file, they should find the disable_functions directive and disable the dangerous functions in it using: disable_function =exec,passthru, shell_exec,system,proc_open, popen,curl_exec, curl_multi_exec,parse_ini_file,show_source PHP also comes with an array of excellent modules; however, not all modules arerequired for every project. In PHP, all the extension modules found in /etc/php.d/ directory are loaded by default. Administrators should get rid of all modules that are not currently required, as doing so will improve both security and performance. To view available PHP modules, use the command: php -m Once you have accessed this list, you will be able to get rid of all unnecessary modules. To enable or disable a particular module, simply find the configuration file in the /etc/php.d/ directory and comment the module name. Scan PHP Scripts & Audit PHP Code for Security Vulnerabilities Scanning PHP scripts and auditing PHP code is essential in identifying and fixing potential security vulnerabilities before they are exploited by attackers. There is a plethora of excellent free and open-source tools and utilities available to assist Linux users in this process. Here are some of our favorites: Phpcs-security-audit is a set of customizable PHP_CodeSniffer rules that identifies security vulnerabilities and weaknesses in PHP code. The tool checks for CVE issues and security adviso ries related to the CMS/framework, enabling administrators to follow the versioning o f components during static code analysis. SensioLabs Security Checker is a command line tool that checks if an application uses dependencies with known security vulnerabilities using the Security Check Web service and the Security Advisories Database . Suhosin is an advanced security system for PHP installations designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. PHP Malware Finder (PMF) is a self-hosted solution designed to help administrators and developers identify potentially malicious code in files. Detection is performed by crawling the filesystem and t esting files against a set of YARA rules. RIPS is a PHP static code analysis tool that is integrated through the development lifecycle to identify security issues in real-time. The toolsupports 15 different types of vulnerabilities, and is able to scan PHP applications very rapidly for PHP-specific vulnerabilities. SonarPHP is a static code analyzer that uses pattern matching and data fl ow techniques to identify vulnerabilities in PHP code. It is used as an extension for the SonarQube platform and features over 200 rules, along with support of custom rules. Dependency-check-cli is a great tool from OWASP that uses dependency-check-core to detect publicly disclosed vulnerabilities associated with the scanned project dependencies. The tool will generate a report listing the dependency, any identified Common Platform Enumeration (CPE) identifiers, and the associated Common Vulnerability and Exposure (CVE) entries. PHP Secure Configuration Checker is a single file that checks a current PHP configuration for potential security flaws. It is user-friendly and has almost no dependencies. The Bottom Line PHP offers web server administrators and web application developers an array of valuable functions and modules paired with robust security inside out - a characteristic that can largely be attributed to the support that PHP receives from the vibrant, global open-source community. However, PHP security is ultimately in the hands of the administrator. He or she must make sure code is written properly, the proper configurations have been made and that the best practices covered in this article are being implemented. PHP security should be a primary concern for administrators and developers, as it is inextricably tied to the security of a web server as a whole. Sound PHP security can help mitigate the risk of attacks and compromise, secure web applications, protect user privacy and maintain a secure and properly functioning Linux web server. Do you have questions about PHP security or want to discuss the topic in more depth? Let’s chat! Connect with us on social media: Twitter | Facebook . In a recent security incident, hackers were able to add a backdoor tothe PHP source code. Although . running, linux, server, prerequisite, popular, applications. . Brittany Day
Jan 02, 2022
•
102
security measuresopen sourcesecurity incidentPHP Server Breach Highlights Urgent Need For Enhanced Security Measures
This weekend’s PHP hack serves as the latest reminder of the importance of server security-and the need to do better. . Just two days ago (Sunday, March 28), hackers were able to breach the internal Git repository of the immensely popular PHP programming language used by almost 80% of all websites on the Internet, and have added a backdoor to the PHP source code. According to a message that the PHP team posted on its mailing list late Sunday night, the malicious code was added to the PHP source code through the accounts of two core PHP team members, Rasmus Lerdorf and Nikita Popov, neither of whom were involved. Popov stated in this message: “We don’t yet know how exactly this happened, but everything points towards a compromise of the git.php.net server.” Luckily, the backdoor mechanism was first spotted by Michael Voříšek , a Czech-based software engineer, before it made it into production. As a result of this security breach, the PHP team made the collective decision on Monday, March 29, to move source code management operations from its internal Git server to its official GitHub account, which will be PHP’s official Git repository going forward. Although we are pleased that this backdoor was mitigated before it made it into production, the incident highlights the need for stronger PHP security through the implementation of preventative server security measures and secure server administration. Had this backdoor made it into production, the malicious code would have allowed threat actors to execute their own malicious PHP commands on victims’ servers. On a broader scale, the majority of attacks on PHP servers can be attributed to misconfigurations and poor server administration. In another notable security incident that occurred less than three years ago which has yet to be explained today, hackers compromised the official website of the PHP PEAR extensions system and hosted a backdoored version of the PHP PEAR package manager for nearly six months. This string ofPHP hacks should serve as a collective call to action for the open-source community to hold open-source projects accountable for the security of their source code and their servers to prevent future vulnerabilities and hacks. And it is not only core team members who are responsible. Users should be contributing to the security of the projects they benefit from, whether it be by reviewing source code, making a donation or helping others get involved. The security of open-source projects is highly dependent upon community involvement, and regardless of your education, experience or skill set, there is something you can do to contribute to the security of Open Source. Right now, attackers are running the show. It’s time to come together as a community and level up! What are your thoughts on this weekend’s hack? Need guidance on how you can get involved in improving PHP security? Let’s chat! Connect with us on social media: Twitter | Facebook . The recent compromise of Apache's server underscores the critical importance of integrating robust security protocols in publicly available software initiatives.. PHP Security, Open Source Security, Server Management. . Brittany Day
Mar 30, 2021
•
102
application securitysql injectionweb securityEssential PHP Security Practices To Avoid SQL Injection Risks
Today on Hacks From Pax we'll be discussing PHP web application security. PHP is a great language for rapidly developing web applications, and is very friendly to beginning programmers, but some of its design can make it difficult to write web apps that are properly secure. We'll discuss some of the main security "gotchas" when developing PHP web applications, from proper user input sanitization to avoiding SQL injection vulnerabilities. . Many PHP application vulnerabilities are caused by not properly initializing variables. This is an example of how PHP, by not requiring the developer to initialize a variable before using it, sacrifices security for ease of use. For example, the following code is easily exploitable. if (user_auth()) { $access = true; } if ($access) { do_sensitive_things(); } This could be exploited by tacking an ?access=true to the end of the url, and the if ($access) test would be passed despite the user_auth() function returning false. This hole could be closed easily by adding a $access = false; at the top of the script, but not all security holes are this easy to spot. Thankfully, PHP now defaults the register_globals option to off. This setting would pass the access variable sent by the url to the script as $_GET[access] rather than just $access . This closes off many of these types of vulnerabilities, but when writing PHP code, especially code for distribution, you should never assume that this option will be set correctly, and always initialize your PHP variables. Users in a shared hosting environment may not have the ability to set these options to their most secure setting. Always initialize PHP variables before using them. Always set register_globals to off, but never write code that assumes this setting. You can use the ini_get() function to determine if register_globals is set at runtime. Another common cause of PHP application holes is improper sanitization of user provided data. For example, if you allow a user to fill out a form and then pass data from a field on that form to a function like system() or exec() the data could contain something malicious, like an ; rm -rf * command tacked onto it. Never trust user provided data. Beware functions that launch system commands, think long and hard about checking any data that is passed to them. Another related but common security flaw in PHP applications is a SQL injection vulnerability. The magic_quotes_gpc option can mitigate this, but as with register_globals you should not assume this setting is on. For example, in your PHP script you might ask the user for a user id and password, and then check for the user by passing the database a query. SELECT * FROM users WHERE name='$username' AND pass='$password'; However, if the user logging in is malicious and devious, he may enter the following as his password: ' OR '1'='1 This causes your query to become: SELECT * FROM users WHERE name='known_user' AND pass=' OR '1'='1'; The user has just logged in with no password, and your application has been penetrated. To avoid this, check for the status of magic_quotes_gpc() using the ini_get() function and if it is disabled, pass all user input that must be included in a query through addslashes() . This will escape the single or double quotes in the user input with backslashes, thereby thwarting the attempted SQL injection attack. Use magic_quotes_gpc , but don't assume it is on or depend on it. The addslashes() function should be used on user data passed to SQL queries. Again, you simply cannot trust user provided data. The PHP online manual contains an entire chapter on PHP security . It's an excellent resource, and goes into much more detail on the PHP security issues I've discussed in this article. Until next time, stay secure, and don't blindly trust any user provided data. -- Pax Dickinson has over ten years ofexperience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian Life Insurance, Philips Electronics and a wide variety of small business consulting roles. . PHP developers must be aware of common security pitfalls such as SQL injection and XSS that can expose applications to threats, implementing effective strategies to mitigate risks. php security, sql injection, secure coding practices. . Brittany Day
Aug 08, 2005
•
102
security measuresphp securityweb serverBest Practices For Securing PHP Installations on Linux Using Apache
As we know that the vulnerabilities in PHP are increasing day by day there comes the need to secure the PHP installation to the highest level. Due to its popularity and its wide usage most of the developers and the administrators will be in trouble if they don't take appropriate steps on security issues during the installation. . First comes the question of choosing the platform for PHP! I have choosen Linux OS and Apache Web server to explain this because of its performance and security aspects. It depends on the developer's need whether he is going to install it as an Apache module or a CGI interpreter. When choosing to build PHP in either of the two ways, you should consider the advantages and drawbacks of each method. Building as a shared object will mean that you can compile apache separately, and you don't have to recompile everything as you add to, or change PHP. Building PHP into apache staticly means that PHP will load and run faster. Advantages Server is more flexible. It can be run as SSL, mod_perl, or php with only one installation. Servers can be extended with other modules even after installation. Easier module development and testing as the compiling apache source is not required each time the module is changed. Disadvantages DSO is not supported on all platforms. Startup of the server is 20% slower due to symbol resolving. The server is approximately 5% slower at execution time under some platforms because position independent code (PIC) sometimes needs complicated assembler tricks for relative addressing which are not necessarily as fast as absolute addressing. DSO can produce a slightly slower server depending on platform and address resolutioning. DSO modules cannot be linked with other DSO modules. For example a.out-based platforms usually don't provide this functionality while ELF-based platforms do. You cannot use the DSO mechanism for all types of modules. This requires either the code be referenced directly through theApache core, or that you compile Apache with chaining available. Some platforms cannot force the linker to export all global symbols for linking DSO and Apache executables. This is overcome using the SHARED_CORE feature of Apache and is used by default on such platforms. Advantages/Disadvantages of compiling PHP as a CGI interpreter PHP can be compiled as a CGI binary, this allows a user to separate PHP from their web server entirely. Each PHP script that is written will need to contain a statement that points to the path of the PHP binary just as in PERL. #!/usr/local/bin/php CERT Advisory CA-96.11 advises against placing any type of interpreter in the CGI-BIN so it is a good idea to create an isolated directory where PHP can be run. PHP has built in security measure to prevent malicious attacks of this type as well. In the configuration file for PHP, you can specify the following security features: doc_root This options only works when PHP is installed in Safe Mode. This specifies where the root document directory of PHP is. Scripts outside of this directory will not be interpreted. User_dir This option only works when PHP is installed in Safe Mode. This variable specifies user directories so that scripts outside of this directory cannot be executed. --enable-force-CGI-redirect This allows you to force redirection so that scripts cannot be access directly from the internet. Scripts are redirected to a URL, hiding their full path names. Building as a CGI Binary means efficiency could be improved by having only a single Perl interpreter running in memory, and passing it the Perl scripts. This is where mod_perl comes in to the picture. It provides a single embedded Perl interpreter within the Apache web server. This can be either statically linked, or as a DSO module. Some of the advantages of mod_perl are: Able to write Apache modules entirely in Perl. Having a persistentinterpreter in the server saves on overheads due to starting a perl interpreter for each script. Offers code caching, where the modules and scripts are being loaded and compiled only once. Increased power and speed. Full access to the web server. Allows customized processing of URI to filename translation, authentication, response generation and logging practically no run-time overhead. Improved performance of %200 - %2000 is apparently obtained. One of the major drawbacks of a CGI interpreter is when PHP is compiled as a CGI. This means a lack of effieciency in handling high traffic applications. PHP installation is very easy but installing PHP in a secured manner depends on your platform, installation type selection, and configuration options considered. Whatever method you choose please remember to follow the recommended PHP Configuration Options. There are various options that can be set in PHP to increase the overall security of your server. We will discuss some of the most common and useful options. Safe_mode Safe mode is required for nearly all of the following options, safe mode allows PHP to impose more security restrictions than a normal configuration. Safe_mode_exec_dir Setting this variable helps you in forceing PHP to only execute scripts from a specified directory. Open_basedir This option allows you to control which directories PHP scripts are allowed to access files from. By default PHP will allow a script to access a file from anywhere so it is recommended that is option be set. By predefining valid directories, data can be protected. Max_execution_time This variable enables you to set a maximum execution time that a script can have. If a script runs longer than the allocated execution time, it will be terminated. This option will allow you to prevent attackers from tying up your web server with malicious scripts that could cause denial of service. Memory_limit This allows you to control the maximumamount of memory that a script can use. Using this will help to prevent buffer overflows which may lead to more serious threats. Upload_tmp_dir This designates where PHP will place files that are being uploaded. We will discuss both cases here. PHP AS AN APACHE MODULE: Here Apache should run as an ordinary user with least privileges. Never run apache as a root user. Try to run Apache in a root jail. If you are running PHP as an Apache Module it is fine, means it provides maximum security. Following are the steps to install and configure the same. gunzip apache_xxx.tar.gz tar -xvf apache_xxx.tar gunzip php-xxx.tar.gz tar -xvf php-xxx.tar cd apache_xxx ./configure --prefix=/www --enable-module=so make make install cd ../php-xxx ./configure --with-mysql --with-apxs=/www/bin/apxs make make install If you decide to change your configuration options after installation, you just have to repeat the last three steps. You also have to restart apache for the new module to take effect. A recompile of Apache is not needed. cp php.ini-dist /usr/local/lib/php.ini You can edit your .ini file to set PHP options. If you prefer this file in another location, use --with-config-file-path=/path in step 8. Edit your httpd.conf or srm.conf file and check that these lines are present and not commented out: AddType application/x-httpd-php .php LoadModule php4_module libexec/libphp4.so The path on the right hand side of the LoadModule statement must point to the path of the PHP module on your system. The above statement is correct for the steps shown above. Different examples of compiling PHP for apache are as follows: ./configure --with-apxs --with-pgsql This will create a libmodphp4.a library, a mod_php4.c and some accompanying files and copy this into the src/modules/php4 directory in the Apache source tree. Then youcompile Apache using --activate-module=src/modules/php4/libphp4.a and the Apache build system will create libphp4.a and link it statically into the httpd binary. The PostgreSQL support is included directly into this httpd binary, so the final result here is a single httpd binary that includes all of Apache and all of PHP. ./configure --with-apache=/path/to/apache_source --with-pgsql=shared ./confgure --enable-debug=no Note: Will not disclose the physical path if some error occurs. ./confgure --enable-safe-mode Banner Off in apache's configuration file httpd.conf, will not disclose the server's banner information. This makes attacks more difficult for would-be intruders. Lets consider the second case... PHP AS A CGI INTERPRETER: Download the latest version of PHP from PHP: Downloads . Extract the package # tar zxvf php-x.x.x.tar.gz Where x.x.x. is the version number. Change to the PHP directory # cd php-x.x.x Configure it with the various options present #./configure --without-apache --without-apxs --enable-force-cgi-redirect This is to tell PHP that it isis built without Apache support and as a CGI binary. You should get the binary in /usr/local/bin/php. Now you know why it is compiled with the --enable-force-cgi-redirect option. The CGI binary isn't compiled within Apache, it runs under a separate process and user. Hence the question comes of placing the CGI binary in a proper location. I would suggest that the CGI binary should be placed outside the web directory, as the risk would be greatly reduced and also make sure that you have enabled safe mode in the php.ini configuration file. Most commonly attacks arise in the form of getting access to files. Therefore you can prevent the user from calling the CGI binary directly by forcing a CGI to redirect within Apache. For this, just add the following directives in Apache's httpd.conf file: Action php-script /cgi-bin/php.cgi AddHandler php-script .php Now you will see that URL is rewritten http;//test.com/application/test.htm into: Note: Ensure that you perform permission checks on the application/directory in the process. This gives you the added benefit of making the URL a little shorter. Lastly, change your doc_root and user_dir options in the php.ini appropriately. SUMMARY: Here we have discussed the issues on how best the user can secure PHP installation considering both cases and I hope this will be helpful to all those who are keen in securing PHP and thus eliminating the many of the security risks involved. Article By: Dharmendra.T Linux Security Expert
Aug 22, 2002
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More