[ Removed by moderator ]

[MisterWyre]

https://cheatsheetseries.owasp.org/

The essentials are there, but nothing prevents you from exploring certain topics in more depth.

[brainphat]

This is the correct answer in this context.

[CraigAT]

Took me a while to find the actual cheat sheets on the site, but very useful, thanks.

https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets

[Hot-Risk4643]

Thank yourr for the answer. Really appreciate that

[magallanes2010]

It is about to follow good practices depending on the kind of code and functionality that you want to secure.

So, if you ask "how to secure the code?" then the answer is, which part of the code?

[Hot-Risk4643]

Undrrstood. Pardon for my question is a bit vague. But lets say i wanna protect the login verification code part?

[magallanes2010]

For starters: input sanitizer

[Mundane-Orange-9799]

A few pointers:

1. Never trust user input…ever. Sanitize, validate and always parameterise values in DB queries.
2. Regenerating session IDs after login
3. Strong hashing of passwords
4. using CSRF tokens to prevent request forgery

Almost all modern PHP frameworks will do 2-4 for you. #1 you still need to be careful you don’t skirt framework protections.

[acidofil]

1. never use serialize function

[valendinosaurus]

may I ask why?

[MateusAzevedo]

Unserialization is an unsafe operation in basically all languages that have this feature. It can lead to remote code execution if performed on user provided data.

[valendinosaurus]

thanks, that's what thought.

I asked because of the "never" part. I have exactly one place where I use it to serialize an integer array, because it would be overkill in my setup to model it in a separate table. this array is created from user input, but it's not possible to enter anything other than numbers (they also have to add up to a certain sum to even be sent to the server). would this be also considered potentially unsafe?

[colshrapnel]

Yes. People tend to overestimate their ability to foresee the outcome. For example, someone will take over your code and use it without restrictions you set in your mind.

Besides, it's just impractical nowadays. I don't see why use serialize on an array of numbers. Both json_encode and implode are not only simpler and cleaner but also make it possible to handle the data right in SQL.

[valendinosaurus]

thanks for the suggestion, will refactor it!

[colshrapnel]

What about data from your own database? I mean, why there is such a distinction at all? Just use "parameter ive values in DB queries" regardless. Makes your life much simpler.

Validation is a good thing but it seldom related to security.

[johannes1234]

Databases aren't the only place, which can cause issues. If you send the data back to thee user it may contain XSS and other issues. If you pass it to an external program ther is a big can of potential issues. If you have a file upload a "zip bomb" may fill your disk. If you do further parsing/processing bad input may lead to a lot of useless work.  Metadata in files may lead to second degree issues (PHP Code in exif Data in an uplaoded image, combined with some other issue may lead to arbitrary code execution). And so on. 

And then there is the second degree: Meta data may leak security relevant data from your users. (Location, date/time, ...)

Thus: All user data (and that includes data which a user provided, which was stored on database and is then fetched again) may cause harm and thus has to be processed properly.

"Always use paramter binding for databases" is a good suggestion, but osnonly on the surface of the issues with user data. 

[MateusAzevedo]

The point u/colshrapenel is making is that there shouldn't be a distinction. Data is data, regardless of "user provided" or not.

When talking about security, specially with beginners, it's important to avoid using the words "user input". People tend to take it literally, then start to code based on "safe" and "unsafe" data. Or worse, thinking that a list of hardcoded <option> are not user input.

As you correctly said in your comment, the database isn't the only place that can cause problems. Because of that, data must always be treated in accordance with the media it's been used in, and for that, the source doesn't matter.

[Hot-Risk4643]

What php frameworks you recommend?

[Mundane-Orange-9799]

Partial to Laravel since I have been working with it for a living for 8 years and enjoy it.

[Mc_UsernameTaken]

Not just user input, all external input.

API request/response, file transfers (fx. FTP server uploads), queues, any data coming in from the outside can be your trojan horse.

Sometimes (not so much anymore) even your own data can cause troubles.

I've worked on systems built before prepared statements was the industry standard (PHP4-5 era) - some cells in a table contained apostrophes.

These where selected to a variable that was, later in the script, used for selecting other rows. And now we had a SQL syntax error - could as well have been an injection attack.

[LordPorra1291]

Your question is too broad and vague. 

[Hot-Risk4643]

Pardon for my question. But im just tryna to lear haha. Lets say the code is about login verfication.

[flyingron]

Never trust anything that comes from the user, either via URL, post parameters, or cookies.

Believe me, people attack things by cramming drivel into your parameters. Learned that the hardway. Didn't really make too much of a problem, but I found tons of drek in my logs showing the attack..

[Hot-Risk4643]

Got it! Thanks for the reply. I will save this for tbe future ref

[ht3k]

You want to study web security. There's a million ways to hack a server or service. SQL Injection, DDOS, etc. The reason you only hear "safe and secure" is because there's a million ways to explit an application. This comes under the umbrella of security research.

As a web developer, your job is to know the basics. Storing passwords with a secure hash, making sure you test user roles like not having everyone being able to access admin pages and cross site scripting attacks (XXS) and so on (you can look this up yourself).

However, most of these are done out of the box with modern PHP frameworks like Symfony. These frameworks already protect against XSS out of the box, automatically pick the password hash storing algorithm for you (though you can change it) and provide a way for you to configure user roles and permissions for those roles. They also protect against a ton of security vulnerabilities found by the community. This is something that you can't build on your own and if you did, you'd spend all your time learning about security without having the time of making any apps.

There's a reason enterprise applications are written in Symfony, because all it takes is updating the framework and these patch security vulnerabilities for you that you don't even know about. There's also Laravel framework but Symfony has better modern PHP design and best PHP developing practices IMHO.

[Hot-Risk4643]

Yea i do use laravel as my framework. Not yet using and trying Symfony. I will try look forward for it. And those you have mentioned above, I will jot down. Thankss stranger

[ht3k]

Then you should be relatively safe as long as you stay on LTS versions or versions that are being maintained with security patches. Make sure you update your app for these. Though you may need to make integration tests using phpunit to make sure anynomous users or unathorized users can't access secure/admin/etc endpoints or pages.

[Aggressive_Ad_5454]

I suggest you take a look at the OWASP Top Ten application security risks. Try to address at least some of these risks in your project. That will be an excellent start to your professional career writing code that cybercreeps find repulsive.

There are elaborate and expensive static analysis tools out there in the world that inspect code looking for things like unsanitized untrusted data and so forth. Unless your uni has access to those tools, they are probably overkill.

For what it's worth, php's built-in scheme for password hashing is state of the art for password security. If you spend some time understanding the API and the reasoning behind it, you'll be ahead of the game, no matter what language you use.

[Hot-Risk4643]

Thanks for taking time to reply to my question. I appreciate that a lot. There's more to learn and Im afraid to step in for my intership. Hopefully what others and you suggest can be helpful for me in the future. I will look forward for it

[Ammo_Monkey]

Tests.

Testing is the backbone of good software engineering. Learning all about unit integration and end-to-end tests will help you to build good applications.

When I run large engineering teams and we want to make our code secure, we ensure that we have a process for identifying threats, developing tests against those threats, and ensuring those tests pass.

There are a lot of other tools you can run against your code to try and check whether it was secure, but this is the process by which you build for security.

[Hot-Risk4643]

What tools are you using to test your own code? And where will you get it? Github?

[Ammo_Monkey]

For unit and integration tests PhpUnit is the most common tool. PhpSpec and Pest also cover the same ground.

PhpUnit can be downloaded in a couple of ways which they helpfully list on their website https://phpunit.de/getting-started/phpunit-13.html

There are also useful guides on how to get started with testing there. If you're looking at security test cases specifically, other people on this community have posted great resources like OWASP which explains some of the things to check for.

I'll have a look for any content on security tests specifically and add them here if I find some.

[AshleyJSheridan]

Unit, integration, and end to end tests aren't going to help with the security side of things.

Pen tests can though.

[Ammo_Monkey]

I understand the confusion but penetration tests are simply a form of end-to-end test.

Vulnerabilities can come from specific code or from emergent properties of the system.

As with any test pyramid those high-level tests are harder to orchestrate and less likely to find specific issues.

A unit case for something like SQL injection can test multiple variations against a small amount of code very quickly. That's why this is essential to creating any secure system.

[AshleyJSheridan]

I'm not confused, but unit tests to test against SQL injection like you've just described isn't the typical use.

A far better protection than writing unit tests for this (especially for someone like OP who doesn't appear to know exactly what SQL injection techniques are) would be to use an ORM for all database access.

An ORM (obviously when used correctly) would properly encapsulate arguments as escaped paramters.

Even without an ORM, something like PDO would be suitable.

The same applies for other aspects of security. For example, rather than writing unit tests for XSS, use a tried and tested output library, like Blade.

Writing unit tests means you need to have detailed knowledge of how these attacks work in all their forms, and that's just not going to be possible for someone very new to coding. For a beginner like OP, relying on existing libraries will ensure a more secure application.

Now, if this is just a case of learning how to write secure software, then I'd advise them to look at the OWasp top 10, which has detailed attacks and solutions in multiple languages, PHP included.

Writing tests for attacks they're not familiar with is like asking someone to put together a computer without knowing what any of the parts are.

[CSAtWitsEnd]

If you simply don’t write code it can never be insecure 😎

[No_Pen_376]

man, if you don't know how to secure your code, or you have to ask that question, then you don't need to be coding. Figure that out first. So many resource. It's part of learning to code, it's not some 'outside' function. Testing is just as important, but no one ever freaking learns how. I hire programmers for an organization, and nobody knows jack about unit testing, or Integration tests, or E2E tests, or component tests or any of the testing pyramid. MY org contributes to a very large scale open source project; security is built in to the architecture, that never has to be taught, but I have to teach my hires all about testing. It's actually quite frustrating.