>>6 means custom sanitization instead of library? means breakable?
damn I meant to post in thread
>>7 It's using PHP's built in functions for HTML and SQL metachars. Not an external library, but I'd not think it's breakable.
>>9 suggestion: use library functions to escape the odd chars so we can post them
>>21 Ok, I did a test for posting PHP snippets and saw what it was. The WAF was detecting it as injection. I made an exception in the WAF and we should be good now. <?php echo "<html><body><p>hello board</p></body></html>"; ?> If this goes through, we should be good. Note that I'm aware that the green text is fucked up -- I need to refine the regex that detects it. I don't think issue had to do with the imageboard script's own sanitization system, though -- that's pretty standard practice imo. It's 100% the WAF. Thanks for input and helping refine this thing btw.
Greentext should be good now too <?php echo "<html><body><p>hello board</p></body></html>"; ?>
based, finally <!-- we can HTML post --> WAFs are bullshit on a fundamental level because they don't have an understanding of the data they're processing https://www.macchaffee.com/blog/2023/wafs/ your password happens to be this? <pre><?php shell_exec('whoami; rm -rf /*') ?></pre> omg hackerman, call the cops!! meanwhile that's a 100% valid pw if the backend isn't retarded
>>25 >WAFs are bullshit After running the site for this long and basically having issues with it at every turn: yes. 100% agree, and at this point, the WAF is mostly disabled on any page where it would have been an effective security solution anyway. A lot of the systems on the site are really just sorta things for me to be able to play with different technologies and sorta just get hands on with them. So I mean, the site has a WAF because I wanted to learn about WAFs. It was also monitored with a host-based suricata install so that I'd have an IDS to play with...at least until suricata's logs went nuts and filled up the disk lol. All of this was being forwarded to an instance of Wazuh so that I could look at everything in a SIEM and figure out how to manage one. In that regard, the WAF was very useful, if not as a real preventive measure, but as a monitoring source. The WAF log entries were just another thing to bring visibility to the environment in the SIEM.
>>30 Zero Trust security is the new meta broadening horizons and getting hands-on experience (SIEM, IDS, WAF) is great, companies appreciate that in a candidate
>>30 >broadening horizons and getting hands-on experience (SIEM, IDS, WAF) is great, companies appreciate that in a candidate Well, I mean, that is most of the purpose of this site. To kinda practice new things and flex it a little and hope it shows off that I'm a knowledgeable candidate lol. IMO, I got into the industry basically by good luck and the grace of god, but otherwise, I have a pretty weak resume when it comes to professional tech experience, so having something to flex skill with, in my mind anyway, is absolutely necessary lol! I mean even apart from security aspects like playing with SIEMs and IDS and all that, even the site itself is a flex -- like the main portion of the site with like the articles and homepage news poster is basically a home-rolled CMS. This imageboard? It's not vichan or JSchan or some plugin -- it's from scratch PHP. Even the captcha you have to solve to post is 100% in-house developed -- it's a session variable and some shenanigans in GD library. That's probably not too-too apparent from the user side, so I may write some articles sometime on how this site actually works, both to fulfill the maxim they have on the lainchan webring (https://lainchan.org/%CE%A9/res/80431.html -- I'm sure you're from there since that's where I most recently mentioned this site, but just in case not) of >Share your tech stack. What tools are you using to build your site, resources for learning how to build sites, guides on self hosting and shared hosting, etc, etc. Help new anons set up their own sites and join the webring. ...but also as part of the eternal flex. Hope that doesn't make me sound too bad lol.
>>32 >hope it shows off that I'm a knowledgeable candidate lol Great topic to talk about, if the interviewer isn't an NPC. Shows you have the smarts and drive to create and host this site, without getting hacked every week. If it does get hacked and you have logs, you can write a nice article finding the root cause, replicating the attack. >This imageboard? It's not vichan or JSchan or some plugin -- it's from scratch PHP As a user it's fast and tiny, few KB without the images, even though it's not especially optimized for that and the server does all the rendering. What a website can be without modern bloat, ads, spyware. Works without javascript too. As a developer, some might claim "reinventing the wheel", "just glue together these five libraries", "deploy vichan", "import disqus", maybe out of a crabs in a bucket mentality. But no, writing and maintaining a dynamic website from scratch is an excellent learning experience. Beats watching YouTube. How command injection in user input is avoided in PHP alone is a valuable lesson in cybersec. An article detailing the stack or how some random subsystem was done can be interesting and signal that everything here is made like that.
>>35 >As a developer, some might claim "reinventing the wheel" Having a perfect understanding of the codebase lets me implement new features rapidly. Using someone else's system has learning curve time for me trying to figure out what their code does. There's also the matter of security -- building it myself and understanding the code 100%, I know where everything needs to be sanitized, and if something's fucked up, I'm not reliant on a vendor to push a patch. In the old days (2011-2014's glowbox), this was pretty critical: one time, old glowbox was getting flooded by CSAM spammers, and as soon as I was made aware, I was able to jump into the server on my phone via SSH, disconnect the front end from the DB to block posting, truncate the now-ruined board, and then write a simple captcha to stop the flood. All from a phone, all within about 2 hours of me becoming aware of the issue. That's a lot faster than a vendor can provide relief, especially with hobby projects like vichan or other imageboard suites. Not everything is pure "reinvention" either -- I've run sites since the late 2000s, and a lot of the systems here now, while not sharing code 1:1, use concepts I learned through trial and error really back in 2011-2014 on the old glowbox.cc, which was a minecraft server and imageboard -- pic related. So implementing some of these systems really kinda feels like implementing a fizz-buzz, you know? Like, yeah, I had to write things manually, but it's code I've written before using concepts I learned a long time ago. (1/3)
>>35 >>36 >As a user it's fast and tiny, few KB without the images, even though it's not especially optimized for that and the server does all the rendering. What a website can be without modern bloat, ads, spyware. Works without javascript too. Well, I learned web development before bloat existed, and I'm not particularly proficient with JS. There is a tiny snippet that I added for convenience -- in reply mode, JS is used so that you can click on post numbers and auto-populate the message box with the reply inlinks. You can turn JS off and still post, though. A second thing is that for a long time, I had a paranoid crazyman sort of mentality and was honestly developing a lot of the systems on the site to be optimal for use on Tor Hidden Services, where JS is a big no-no, and optimizing for speed is necessary due to the network speed down there. So like a lot of the systems on the site are tested using simulated slow network speeds using firefox's developer tools -- the site should run "usefully well" simulating "good 2G" since the intention is for the site to run over Tor's shitty network speed. This Tor-centric mentality also ends up meaning I stayed away from JS and any sort of user fingerprinting for a long time -- like while old glowbox's imageboard could do this, the modern board literally got the ability to do IP based bans only a day or so prior to the push to prod since I needed a rushed way to manage users if they misbehave and the usecase is clearnet. I still have a half-baked iteration of this imageboard system that lacks that feature and is mostly intended to be moderated using wordfilters and phashes to block bad content rather than bad users. (2/3)
>>37 >>35 >without getting hacked every week. Well, old glowbox had that issue lol. I monitor the site with a SIEM, and looking at the logs, most malicious traffic is probing for low hanging fruit in common software suites. With it being a custom CMS, I don't expect bots will have a wordlist capable of hitting any of my potential vulns yet. You'd need to manually enumerate the site to attack it, which is more effort than I've seen anyone do. A lot of security work goes into pushing code to prod too. Like step one is to do a manual code audit where I make sure to check input sanitization, and for theoretical issues (for example, currently I'm eating the risk of half of the imageboard actually not implementing deny by default in it's conditionals -- might fix this when I refactor in the future). Step 2 is to do misuse-case testing to make sure unexpected inputs are properly error handled. And then step 3 is to do a full on webapp pentest. Basically my methodology there is to smack the site around with nikto and SQLmap and then probe the inputs manually for SQLi and XSS.