Realized during the port the PHP site had been att...
# kobalt
c
Realized during the port the PHP site had been attacked many times and had a lot of spam in its database, but none user visible. At least now I’m much more confident in the security.
j
@cedric I thought that was a completely static site? What was the DB for? Also, anything that may impact users of TestNG or similar?
c
@jlleitschuh DB? There’s no DB for the TestNG site, it’s all static. The web site I rebuilt in Kotlin recently is a different one, https://www.perryrhodan.us
j
Ah! Okay.
c
Kotlin, Exposed, Guice, DropWizard. Pretty simple stack but super effective, and I think pretty robust so far.
j
For the DB did you use prepared statements? Or is that what got you in the old one?
c
That’s Exposed’s job, not mine 🙂
I hope the DSL they offer does issue safe SQL queries
and either way, none of these are exposed in URL’s obviously
j
Right, yes. It should be. Is that what got you on the PHP site?
c
Actually no, it was pretty safe there, but there’s a mechanism where people can submit summaries anonymously. These go into a
pending
table until I can review them. That’s what spammers used. Not realizing this content is never exposed until I approve it
I got also a few other attacks, people trying to download unauthorized files from PHP, etc… but these were defeated by my host, as far as I can tell
j
Bahahah. Ah! Yea. Gotta integrate something like Google's reCAPTCHA
Most of the "attacks" are probably just random internet scans and automated tools.
It's like the wild west out there.
c
Yes. At least with a Kotlin/DropWizard site, I feel pretty safe
j
You really have to be careful about upload when it comes to PHP sites. If you can upload a PHP file to a server and then get the webserver to run it, you have an instant reverse shell. Nothing similar I'm aware of with the Java ecosystem, unless you have dynamic classloading from arbitrary paths, but at least that's not something Java will support by default. Is the HTML all Kotlin generated as well?
c
Learned that namecheap is not compatible about SSL with heroku though, so lesson learned
HTML is server side mustache.
j
Who'd you use for SSL then? Lets Encrypt?
c
Yes Let’s Encrypt. It kind of works over all but redirects for domains doesn’t 100%
I will switch to another provider, that needs to support
A
records (which namecheap doesn’t)
j
If you let anyone upload custom content, you need to be careful about mustache. I don't know if it does HTML escaping meaning you can have a user submit javascript which will be stored and can be run in another users browser. Not a huge deal though here because you don't have a "login" where someone could risk loosing something valuable.
But, just as a general precaution.
c
Fair point.
j
Any updates on getting the TestNG site to automatically redirect all port 80 requests to port 443?
Also, you're still suggesting users resolve testNG insecurely here: http://testng.org/doc/download.html
<url>http://jcenter.bintray.com</url>
c
That I can fix easily
j
🎆
I just sent an email to Jfrog Bintray and Sonatype suggesting they drop support for resolving artifacts over http starting in early 2020.
c
Try again for the redirect, @jlleitschuh
j
@cedric No cigar.
c
Really? I just clicked on your URL above and landed on https
j
Actually, it worked. I had to try it in an incognito tab
It was just that chrome had it cached.
c
Cool.
Also did a global replace of http->https on most of the doc, for my domains anyway
j
while you're already in there, do you want to add the strict transport security header? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
c
Sounds more complicated than what I’m wishing to do right now 🙂
j
It will tell browsers to "remember" to use htttps so your sever won't have to tell them to redirect.
Fair enough
Alright, I'm off. Please do try to fix the documentation that tells users to use:
Copy code
<url>http://jcenter.bintray.com</url>
I'm already seeing it in far too many open source projects.