Understand PCI compliance and its impact on PHP development
PCI stands for the “payment card industry”, but for many it is a set of vague standards imposed by Secret International Cartels that aim to bury unsuspecting souls with heavy statutes and legal disputes . The truth is much more boring. In fact, PCI is a set of security guidelines developed by a coalition of credit card companies and industry security experts to regulate how applications behave when processing credit or debit card information. Credit card companies impose these standards on banks, which banks then impose on those of us who operate e-commerce websites. In this article, we will remove some persistent misunderstandings about PCI, learn about PCI from a height of 20,000 feet, and then focus on those requirements related to general coding and PHP.
Key Points
PCI misunderstanding
No wonder, there are many misunderstandings around the PCI standard. One of the misunderstandings is that they are like the mafia code of conduct, not written anywhere, so they can be interpreted the way you want. Of course, this is incorrect. To learn the complete description of PCI standards, just visit pcisecuritystandards.org. Another misunderstanding is that PCI safety standards only apply to "big companies" such as banks and large retailers. They are suitable for everyone who accepts credit card information to pay for the goods. If you wrote a PHP website for your mother to sell her famous lemon pie, you have a system that fits the PCI guidelines. The third misconception is that if you follow PCI standards, you will be protected from malicious hacking and your data will remain secure. Of course, this is good, but the truth is that PCI standards are guides and ideas, not specific techniques (they have to be vague to fit all architectures and platforms). Obviously, the more you focus on security, the less chance you will be attacked, but anyone can be attacked. If you have at least tried to meet PCI expectations, then your review will be better both in terms of law and consumer. Finally, PCI is not something you can accomplish with just one and then take a deep breath. This standard requires you to do a PCI review once a year, so it is like quality assurance work or listening to your spouse, an ongoing work. The simple fact is that PCI is something that every programmer working on an application that processes credit card data needs to know, regardless of size. Yes, that's why dealers only collect cash.
Basics of PCI
PCI standard consists of 12 basic requirements. The standard is updated approximately every two years, during which a variety of more specific guide files are published that deal with a subset of the PCI world. For example, in February 2013, PCI staff published a white paper discussing PCI and cloud computing. These special reports are also available from the PCI website. As we will see, many PCI requirements are more network-related, but if you don't have a basic understanding of full PCI, what's the point of talking about these things? These requirements are:
Some of these projects are related to policy decisions, i.e., decisions that clearly state how you work to protect card information and ensure overall security of the network and applications. Other requirements have to do with the network itself and the software you can use to protect it. Some of them involve the design phase of the process, how you build and set up your application. There are few requirements related to code, and there are no requirements to describe specific programming techniques that recommend you stay safe. To keep the length relatively short, I will limit my irony and wisdom (70:30 ratio) and focus on the last two groups.
Requirement 2 - Do not use the vendor's default configuration file/password
In many ways, this is almost self-evident. Security personnel have been telling us this since we started worrying about these things. But it's surprising how easy it is to use a default account and password in many of the software we use (such as MySQL) (especially when you first install something and everything is in "test" state). The danger here increases because most of us build our applications around some basic software, rather than doing the whole thing from scratch. It might just be a package we use to handle encryption and key storage (see below), or it might be the framework for the entire application. Either way, easy to remember, easy to implement: don't use the default account.
Requirement 3 - Protect stored cardholder data
In most high-profile retail website hacks I remember, there were involves theft of cards or other data saved by the website, so I listed this as the most important part of the PCI standard. Obviously, any card data you store should be encrypted. And you need to do a good job of encryption. For those who know encryption very well, you know that doing a good job of data encryption means you have managed encryption keys well. Key management revolves around the issue of generating, storing, and updating keys used in encryption processes. Storing them can be a big problem because you want to make sure no one can get into the system and steal the keys. Management strategies vary in how to divide a key into multiple parts; if you want to know about the introduction to key management, I suggest you start with this white paper from Securosis and continue to study, although be aware that the water will change quickly Very deep. Of course, if you use commercial products to handle encryption, you can leave key management to them, although you want to make sure their process is reliable and that it fits your approach. Most commercial products are developed with PCI in mind and will therefore be built according to PCI standards, but this still won't prevent you from performing a secondary inspection. Additionally, if you minimize or even eliminate the amount of data you store, the task of protecting data will become much easier. That is, the cardholder data can be their name, birthday, card number, validity period, card verification (CV) code (three or four digits on the back or front of the card), etc. The fewer items you save, the less you need to encrypt, and the less responsibility you have. Fortunately, this is a pretty specific area of PCI standards that clearly define what data you can and cannot save. You can save the card number (PAN – main account number), cardholder name, expiration date and service code. If you do save a PAN, then if you want to display it, you have to block it, and only the first six and last four digits can be displayed at most. You cannot store the entire contents of a PIN, CV code, or magnetic stripe. The question you have to ask yourself during the design phase is how much of this annoying data you really want to keep. The only real reason to keep it is that you want to provide an easy experience for your customers the next time. You can keep your birthday so you can send them a friendly little invitation on your birthday. All this data must be encrypted and protected, so make sure you get some reliable commercial use from it. Requirement 4 (encrypting any data being transmitted) is considered part of this part, but I will consider it as part of the infrastructure and will not go into details.
Requirement 6 - Develop and maintain secure systems and applications
This is a code-related requirement. Not targeting a specific function or class, but at least make sure you follow general safety standards and try to make your stuff as safe as possible. So you just use coding techniques (regardless of language) that won't make your application vulnerable to obvious attacks. For example, you try to prevent SQL injection by taking precautions when accepting form data, you try to block XSS, etc. For more information on avoiding some of the more common security issues, see some other articles posted on SitePoint (this article and this article, and other articles you can find if you search for "Safe".
Requires 7 and 8 – Restricted access and unique IDs
Both of these things are related to the way you access your application, so it's somewhere between coding and design. It should be no problem to require each visitor to have a unique ID unless - you happen to allow people to log in and shop through the guest profile. I can think of several websites that allow you to do this, which is not evil in itself, but using group profiles is dangerous and you have to be extra careful to make sure they don't have much permission. Generally speaking, you should try to set a unique ID, even if the ID is not the ID you saved. For example, you can have people log in as a guest, but then immediately create a unique configuration file for the event in the background. We also want to limit physical access to cardholder data. This may be a hint of the future, when we will be able to shrink people to submicroscopic sizes like Isaac Asimov's Fantastic Journey and inject them into the storage device to get the 1 and 1 of the card data 0…or it may also be related to locked server rooms, badges for all visitors, not allowing anyone to get close to backup tapes, etc.
Requirements 10 - Tracking and recording all access to resources/data
Lastly, don't underestimate the importance of tracking and recording everything that accesses resources or cardholder data...I mean everything. Events that should be recorded include login, logout, data access; data updates, in fact anything that involves resources or data elements and that you think may be useful for evidence in audit trails or criminal trials. You must implement a secure log that checks the logs every day to find problems and saves the logs for one year. For PHP users, it would be beneficial to be familiar with the PSR-3 logging standard from the PHP-FIG group, which provides a unified and flexible way to set up your logging. Rather than diving into it in depth here, I suggest you read Patrick Mulvey’s introductory article.
Summary
One thing I want to really emphasize is that PCI is not the icing on the cake. It is the basic part of creating an application that uses credit card data. If you are writing an application that does receive this kind of data, it will work for you regardless of whether your customers know it or not. Most of the content is above the encoding level, but it is real and you still have to pay attention to it. Pictures from Fotolia
FAQs (FAQs) about PCI Compliance and PHP Development
PCI compliance refers to compliance with the Payment Card Industry Data Security Standard (PCI DSS), a set of security standards designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment. For PHP developers, understanding and implementing PCI compliance is crucial as it helps protect customers’ sensitive data, reduce the risk of data breaches, and build trust with users. Failure to comply with regulations can lead to penalties, fines, and even the loss of the ability to process payments.
PHP developers can ensure PCI compliance through several key steps. These steps include using secure coding practices to prevent common vulnerabilities, encrypting sensitive data, implementing powerful access controls, regularly testing and updating systems and applications, and maintaining information security policies.
Some common security vulnerabilities in PHP include SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). These vulnerabilities can be prevented by using pre-prepared statements or parameterized queries to prevent SQL injection, validate and clean user input, and anti-CSRF tokens to prevent CSRF attacks.
PHP developers can process credit card data securely by following PCI DSS requirements. This includes encrypting cardholder data transmitted on an open public network, protecting stored cardholder data, implementing powerful access controls, regularly monitoring and testing the network, and maintaining information security policies.
Encryption plays a crucial role in PCI compliance. It helps protect sensitive data by converting sensitive data such as credit card information into a format that cannot be read, which can only be decrypted using a decryption key. This ensures that even if the data is intercepted during transmission, unauthorized individuals cannot read or use it.
PHP developers can limit physical access to cardholder data by ensuring that each person with computer access is assigned a unique ID, and restrict access to cardholder data based on principles that business needs to know Implement strong access control measures. In addition, they should review access controls regularly and update them as needed.
Failure to comply with PCI DSS can lead to a range of consequences, including fines, penalties, and even the loss of the ability to process credit card payments. In addition, it can damage the company's reputation and lead to a decline in customer trust.
PHP developers should regularly test their systems and applications for security vulnerabilities. The frequency of testing will depend on the specific requirements of PCI DSS, but as best practice, systems and applications should be tested at least once a year, as well as after any significant changes.
Information security policy is a set of rules and procedures followed by a company to protect its information assets. It is important for PCI compliance because it helps ensure that all employees understand their roles and responsibilities in protecting cardholder data and provides a framework for implementing and maintaining security controls.
PHP developers can stay up to date with the latest PCI DSS requirements and by regularly checking the official PCI Security Standards Committee website, subscribing to relevant security newsletters and blogs, attending security conferences and webinars, and participating in security training and certification programs Safety best practices.
The above is the detailed content of PHP Master | PCI Compliance and What it Means to PHP. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
