Show HN: I made CMS less than 15 kilobytes, flat file
44 comments
As who has endured the old Web 1.0 era with PHP, I can immediately see that the author didn't have any benefit of hindsight: no error handling, no XSS protection, no CSRF protection, no atomic file writing, no correct permission in the data directory (which means that some settings are still required depending on your webserver), no real way to change password which is built into admin.php, no constant-time comparison on login, no correct template handling (it may or may not recursively expand included files depending on the order!), unlimited writes to the session even when credentials do not match, and of course no protection against any attempt to use fopen wrappers after login. And the supposed "content" management system doesn't allow any file uploading.
The author needs to be a lot more careful about security at the very least. To be precise, PHP is not the culprit here, but does enable lots of easy ways to make your program immediately insecure due to its interface and one has to learn how to avoid them systematically.
The author needs to be a lot more careful about security at the very least. To be precise, PHP is not the culprit here, but does enable lots of easy ways to make your program immediately insecure due to its interface and one has to learn how to avoid them systematically.
There is a newer version on GitHub, and the very first version is on this site. Compare them and you will see the difference.
I compared them - and you're still not sanitising the $_POST inputs amongst some other bad practices. So it's great that you've made this and put a substantial number of hours into creating themes for it - but in it's current state (looking at all the branches in your github) it's not fit for purpose.
If you hosted this online, you're simply providing a platform for malicious users to gather targets or worse.
What was/is the goal of this project? To make the smallest CMS? To try your hand at making a CMS and to learn from it? This is unclear.
If you hosted this online, you're simply providing a platform for malicious users to gather targets or worse.
What was/is the goal of this project? To make the smallest CMS? To try your hand at making a CMS and to learn from it? This is unclear.
On github under the first two screenshots I very clearly expressed why I created this, the root cause was and remains the same, I want to continue to improve this script, but the most important task for me was backward compatibility, and simplicity. I love old time-tested technologies, this script (but improved) with additional functionality works as an admin panel on the hosting. I indicated this in the topic. on the hosting site there is our common goal - we are creating a community
if you have a solution - I will be happy to consider it and use it
P.S. the script does not collect cookies and works on text files. That's probably why this method
if you have a solution - I will be happy to consider it and use it
P.S. the script does not collect cookies and works on text files. That's probably why this method
Keeping an XSS-prone version to your website still allows abusing, like the following:
http://old.net.eu.org/index.php?p=%3C/title%3E%3Cmeta%20http...
Fix it ASAP if you don't want to be associated with any fault caused by attackers.
http://old.net.eu.org/index.php?p=%3C/title%3E%3Cmeta%20http...
Fix it ASAP if you don't want to be associated with any fault caused by attackers.
thank you very much for your feedback, I am very grateful to you for studying the script in detail, I have not had such detailed criticism from anyone before. I will gradually take your comments into account, because what I do is very important to me, and I also want it to be useful for others. useful and painless. If you can help me at least a little with solutions - I will really look forward to your letter [email protected]
I prefer to post issues to the public because that benefits more people in general. Not always true for security issues, but somehow miraculously, I didn't spot any severe issue to warrant that yet. So the following is a bit more detailed explanation for each item.
"No error handling." You need to check absolutely any unexpected situation in general. For example, I can easily trigger a PHP warning with a null character (https://old.net.eu.org?p=asdf%00asdf). These file names directly go into the content file path, only going through some "sanitization" steps that remove /, \ and ".txt". Don't do that, instead only accept a class of characters that you are absolutely sure to be safe.
"No XSS protection." Cross-site scripting (XSS) allows attackers to inject some unrestricted contents into the output, and the systematic way is to escape virtually everything with htmlspecialchars() and so on. Many modern web frameworks even do escaping by default unless explicitly instructed to, but PHP is too old to benefit from that. Be absolutely pedantic about escaping; there are several places with missing escapes in admin.php, while index.php doesn't have one by itself at least for now. (XSS in the title is probably from a custom modification.)
"No CSRF protection." Cross-site request forgery (CSRF) is possible when destructive commands can be sent outside of the origin website. Specifically, if the session is already enabled and some external website has a form that links to admin.php with a destructive command, that command will be immediately executed regardless of its origin due to the HTML form's legacy requirement. There are many mitigations, but the easiest applicable way would be to add random bytes to the session on login and require the form to resend that bytes on command. Of course details matter a lot, like how those random bytes are generated.
"No atomic file writing." Different storage methods have different guarantees for the stored data and applicable operations. Filesystems typically have a strong guarantee that no operation or (temporary) disruption renders the whole filesystem unusable, while the data itself is subject to much more relaxed guarantees unless specifically requested. In your case, any file update may be interrupted in the middle and that partial write will be present after the interruption. (And of course multiple updates to the same file in parallel will result in an interleaved file.) I think there is no built-in PHP function for atomic file writing (and no, file_put_contents can't do that), so you need to make one.
"No correct permission in the data directory." It is, to my knowledge, still common that a webserver runs as its own user distinct from everyone else. So any filesystem access will be done as that user, and especially file writes won't be possible unless the data directory is set to allow that. Many webserver-writable directories had too many permissions enabled for anyone (e.g. chmod 777) as a result. You should have some solution to guide users to set the correct and only necessary permission on such cases, and that requires some understanding about UNIX permission system.
"No real way to change password which is built into admin.php." This is probably what most users would expect to be able to do. Also password is written in a plain text, which is yet another potential issue but probably less important in this particular setting as long as HTTPS is used. (You may want to always enforce HTTPS for that reason.)
"No constant-time comparison on login." Any credential comparison might be vulnerable to the timing attack, which uses the fact that the time to do a short-circuited comparison reveals how long prefix does match. PHP does have a dedicated `hash_equals` function that compares both strings all the way, though it (and any other such functions) does necessarily reveal the length of password, which is why we have password hashing functions in general.
"No correct template handling." Any pattern of [[foo.txt]] will be replaced. But the actual replacement is done with str_replace, which means that if foo.txt had [[bar.txt]] then it might or might not be replaced depending on whether [[bar.txt]] was also in the original file. Use `preg_replace_callback` instead, possibly with a cache to read any included file at most once. You might also implement recursive templating with some more logics.
"Unlimited writes to the session even when credentials do not match." The admin.php file doesn't actually have no login action, instead it overwrites $_POST[...] to $_SESSION[...] whenever they present before the actual checking. So an attacker might not be able to log on, but might be able to use a large amount of session storage which is only bounded by the maximum memory limit. The checking should be done before writing anything into the session storage instead.
"No protection against any attempt to use fopen wrappers after login." PHP (still) has a questionable feature to accept URLs in place of file paths, which can be used to send an attacker-controlled request to other servers for example. Index.php always constructs any path with a fixed prefix so this attack is impossible, however only accidentally. Admin.php doesn't fully protect the attack though.
Finally, file uploading would be quite difficult to implement safely. This is because PHP used to work "transparently" from views of web servers, so if you expose the uploaded file directory in public, then that directory is no different from the directory that hosts index.php and admin.php. That directory should be ideally hidden from the public view for this reason, and some dedicated script should be instead used for serving any uploaded file. Do not use an allowed file extension list alone to solve this, there exist many workarounds for that.
"No error handling." You need to check absolutely any unexpected situation in general. For example, I can easily trigger a PHP warning with a null character (https://old.net.eu.org?p=asdf%00asdf). These file names directly go into the content file path, only going through some "sanitization" steps that remove /, \ and ".txt". Don't do that, instead only accept a class of characters that you are absolutely sure to be safe.
"No XSS protection." Cross-site scripting (XSS) allows attackers to inject some unrestricted contents into the output, and the systematic way is to escape virtually everything with htmlspecialchars() and so on. Many modern web frameworks even do escaping by default unless explicitly instructed to, but PHP is too old to benefit from that. Be absolutely pedantic about escaping; there are several places with missing escapes in admin.php, while index.php doesn't have one by itself at least for now. (XSS in the title is probably from a custom modification.)
"No CSRF protection." Cross-site request forgery (CSRF) is possible when destructive commands can be sent outside of the origin website. Specifically, if the session is already enabled and some external website has a form that links to admin.php with a destructive command, that command will be immediately executed regardless of its origin due to the HTML form's legacy requirement. There are many mitigations, but the easiest applicable way would be to add random bytes to the session on login and require the form to resend that bytes on command. Of course details matter a lot, like how those random bytes are generated.
"No atomic file writing." Different storage methods have different guarantees for the stored data and applicable operations. Filesystems typically have a strong guarantee that no operation or (temporary) disruption renders the whole filesystem unusable, while the data itself is subject to much more relaxed guarantees unless specifically requested. In your case, any file update may be interrupted in the middle and that partial write will be present after the interruption. (And of course multiple updates to the same file in parallel will result in an interleaved file.) I think there is no built-in PHP function for atomic file writing (and no, file_put_contents can't do that), so you need to make one.
"No correct permission in the data directory." It is, to my knowledge, still common that a webserver runs as its own user distinct from everyone else. So any filesystem access will be done as that user, and especially file writes won't be possible unless the data directory is set to allow that. Many webserver-writable directories had too many permissions enabled for anyone (e.g. chmod 777) as a result. You should have some solution to guide users to set the correct and only necessary permission on such cases, and that requires some understanding about UNIX permission system.
"No real way to change password which is built into admin.php." This is probably what most users would expect to be able to do. Also password is written in a plain text, which is yet another potential issue but probably less important in this particular setting as long as HTTPS is used. (You may want to always enforce HTTPS for that reason.)
"No constant-time comparison on login." Any credential comparison might be vulnerable to the timing attack, which uses the fact that the time to do a short-circuited comparison reveals how long prefix does match. PHP does have a dedicated `hash_equals` function that compares both strings all the way, though it (and any other such functions) does necessarily reveal the length of password, which is why we have password hashing functions in general.
"No correct template handling." Any pattern of [[foo.txt]] will be replaced. But the actual replacement is done with str_replace, which means that if foo.txt had [[bar.txt]] then it might or might not be replaced depending on whether [[bar.txt]] was also in the original file. Use `preg_replace_callback` instead, possibly with a cache to read any included file at most once. You might also implement recursive templating with some more logics.
"Unlimited writes to the session even when credentials do not match." The admin.php file doesn't actually have no login action, instead it overwrites $_POST[...] to $_SESSION[...] whenever they present before the actual checking. So an attacker might not be able to log on, but might be able to use a large amount of session storage which is only bounded by the maximum memory limit. The checking should be done before writing anything into the session storage instead.
"No protection against any attempt to use fopen wrappers after login." PHP (still) has a questionable feature to accept URLs in place of file paths, which can be used to send an attacker-controlled request to other servers for example. Index.php always constructs any path with a fixed prefix so this attack is impossible, however only accidentally. Admin.php doesn't fully protect the attack though.
Finally, file uploading would be quite difficult to implement safely. This is because PHP used to work "transparently" from views of web servers, so if you expose the uploaded file directory in public, then that directory is no different from the directory that hosts index.php and admin.php. That directory should be ideally hidden from the public view for this reason, and some dedicated script should be instead used for serving any uploaded file. Do not use an allowed file extension list alone to solve this, there exist many workarounds for that.
did you test the version on the site, what about the version on github? the difference between them is half a year, and several releases. the site has the very first version of the script, naturally there were errors then, but I thought you were looking at the latest
I only looked at Github and didn't realize the website used an older version until you said so. (I wondered why admin.php didn't seem to exist.) These issues are so well-known enough that I didn't even have to run the script at all.
the admin panel can be renamed. this does not affect the functionality. they are not linked. it may not exist at all
another addition - the system is single-user, it was created for a business card site, not for a blog or a corporate site, there can't be more than one user here. that's the idea, it's made for small net, it's not another wordpress with frameworks, it's created for the simplest tasks
another addition - the system is single-user, it was created for a business card site, not for a blog or a corporate site, there can't be more than one user here. that's the idea, it's made for small net, it's not another wordpress with frameworks, it's created for the simplest tasks
Yes that was what I assumed, but it ideally should be safe without the renaming. Security by obscurity only works to the limited extent.
and by the way - thank you very much for your comments, you really help, I will try to take into account all these points, it is impossible to take everything into account at once, this is a human factor, in general I thought to expand the functionality a little, but you showed me the problems that need to be (and can be) solved. nevertheless, if you have a solution to the problems, you know my email, I will be very grateful. although you have already saved me a lot of time without this. thank you
Replying with a ChatGPT response doesn't quite convey sincerity I'd say.
Why are you so aggressive?
There's no aggression meant in my comment, just an attempt to give some feedback in how you might be perceived when you respond in a certain way.
I guess I understood you: diplomacy and accuracy lose the humanity of the answer?
It's more like: if you didn't care enough to write the answer yourself, did you care to read or take the feedback to heart?
I understand that you can’t accept the fact that I wrote the answer personally?
To me it sounded exactly like ChatGPT, a writing style that shouldn't be emulated unless you risk coming off as nonchalant.
and where do you think the gpt chat learned to write in such a style? I understand that our dialogue is an attempt to hurt me, nothing more
It's definitely not an attempt to hurt you...
While the effort is welcomed, one has to start somewhere, this is more like a "Hello World CMS".
the start is really very good, and there are already more than 300 registrations on the hosting.
can i hide all the posts before login,which is what cms good for,else it looks similar to SSG to me,thanks
Thank you very much for your feedback, I really appreciate it
oh - some of those designs in the examples (quark, 0832) take me back. Pure nostalgia. Thank you.
I'm glad you like it, there are already 99 templates on the hosting
Nice but calling this a CMS is a little bit over the top
The main thing is that the script does its job, right?
Those little GIFs bring a tear to my nostalgic eyes.
The "Under construction" one :-)
Welcome to the community ;-)
Are you commenting on your own posts from different accounts?
kopakobana and joobadze only comment on and promote your things.
kopakobana and joobadze only comment on and promote your things.
These guys have been using hosting for a long time, I asked them to support me. One is Georgian, the second is from Western Europe.
[deleted]
Starred you too, pretty nice CMS and templates!
I'm very glad that you liked it, thank you for your feedback
joobadze(1)
http://web1.0hosting.net/ - free hosting based on this CMS