Merge the sections 4.7.11.1 & 4.7.11.2

[jespunya]

What would you like to happen?
The sections 4.7.11.1 Testing for Local File Inclusion & 4.7.11.2 Testing for Remote File Inclusion address two attack vectors that are very similar one to the other. Given this situation and the few documentation on the Remote injection one, my proposal would be to merge both in a single section called Testing for File Injection.

[victoriadrake]

Thank you @jespunya! Are you willing to tackle a first draft of this?

[jespunya]

I can do it if there is consensus about it

[kingthorin]

I haven't looked at the content yet. But these are level 4 sections so the separation does actually represent two topics (IDs) but does make things easy for editing/maintenance. If there's some benefit to merging them then go for it, but if it just creates a ridiculously monolithic page then it might be better to keep it small and more easily maintainable (IMHO).

(There are actually parts earlier on in the guide that I think should be broken up, but that's a topic for another day.)

If they are merged, the naming should remain as "Inclusion" and not become "Injection".

[jespunya]

Totally agree about the Injection --> Inclusion. It was my mistake, I wrote it too fast.

[ThunderSon]

This adds on Rick's comment. These 2 scenarios have no IDs, so are not a big issue in terms of structure.

My question to you @jespunya would be the following:
If we go ahead and merge them all into one section (Code Inclusion or whatever we decide on naming it), how will the testing steps be defined, how will the recommendations be, and will they be properly separated? Or will there be some sort of confusion when advising against a certain attack?

[jespunya]

@ThunderSon I didn't think on those details. My idea was just a big picture proposal.

Even though, I agree with you that the different tests should be in some how separated.

Maybe we could have a structure such as:

• What's file inclusion as general concept
• Difference between Local & Remote File Injection as different attack taxonomy vectors
• Deep exposure of the LFI
• Deep exposure of the RFI
• Remediations
• Tools

[ThunderSon]

The idea that all of these follow is code injection. It happens in various ways and methods. If you want, just as a visualization effort to just try to cram them all under one file.
What do you feel like doing about this? Let me try to understand better how we can work on this effort.

What you're proposing could definitely be needed. The Section 4.11 is not a biggie or anything of important. 4.11.1 became much more detailed after you added your work into it. 4.11.2 has a little tiny bit of information. What's going to differ is a bit the parsing on the backend, and the used injection attack (instead of a filename straight up, it's gonna be a remote one).

Would love to see how you might consider this. Remediation should be very similar, that's for sure. We can even just reference the cheat sheets which will make things much smoother.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.