| Time |
S |
Nick |
Message |
| 05:53 |
|
|
deep-book-gk_ joined #sourcefu |
| 05:53 |
|
|
deep-book-gk_ left #sourcefu |
| 20:04 |
|
prologic |
Anyone want to collaborate with me on putting together a Gist that outlines a checklist of things you should tick off when designing a secure web application or api? |
| 20:16 |
|
bear |
that's like asking what your fav editor features are |
| 20:17 |
|
bear |
the first 10 are easy |
| 20:18 |
|
bear |
- be able to work from either a subdomain or a non-root path |
| 20:18 |
|
bear |
- avoid /# like the plague |
| 20:19 |
|
bear |
- do not have anything but a redirect to https for the http route |
| 20:20 |
|
bear |
- no url params, all payload |
| 20:20 |
|
bear |
- access token auth, no passwords |
| 20:21 |
|
bear |
- CSRF |
| 20:21 |
|
bear |
- XSS |
| 20:21 |
|
bear |
- avoid "rest" and keep the data routes (aka the api) distinct from the html routes |
| 20:22 |
|
bear |
there that's off of the top of my head as an SRE person and not a web dev |
| 20:23 |
|
bear |
oh! be a truly progressive web app and work fully without javascript |
| 20:39 |
|
prologic |
this is a good start |
| 20:39 |
|
prologic |
and I have a checklist of my own too based on experience and research |
| 20:40 |
|
bear |
haven't even gotten to the fun part of frontend/backend, json/xml, etc |
| 20:40 |
|
prologic |
my goal is a simplifed checklist you can easily follow (assuming you already have extensive development experience) with a small subset of recommended libraries |
| 20:40 |
|
prologic |
I know :D |
| 20:40 |
|
bear |
right - a list of items to help narrow down the choices you want to make |
| 20:41 |
|
prologic |
password security |
| 20:41 |
|
bear |
- do you need offline access? |
| 20:41 |
|
prologic |
bcrypt/scrypt |
| 20:41 |
|
prologic |
don't care about offline access :) |
| 20:41 |
|
bear |
ah - see, that's why I said access tokens, no passwords |
| 20:41 |
|
prologic |
but yes you have the idea -- a narrow list of things to check off |
| 20:41 |
|
prologic |
if by access tokens you mean OTP/U2F |
| 20:41 |
|
prologic |
then yes |
| 20:42 |
|
prologic |
I absolutely do not ever think you should rely on a user/pass set of credentials ever (these days) |
| 20:42 |
|
prologic |
even if that means educating users to use a god damn security token :) |
| 20:43 |
|
bear |
yea, i'm talking about some sort of intitial sign-in (yes, passwords if you have to) that generates a token and then regenerate said token with OTP verification as needed |
| 20:44 |
|
prologic |
my use-case btw and motivation (btw) is I'm building a web app I want to potentially expose to a subset of select friends/family over the web and since I'm a paranoid bastard I need to check off all the right checks/balances to ensure maximum security (without making things *TOO HARD*) |
| 20:44 |
|
bear |
yep, the indieweb folk are having that same problem - how do you share certain items with friends/family but not require them to be security trained |
| 20:44 |
|
prologic |
My plan actually is to use U2F |
| 20:45 |
|
bear |
yubikey style ? |
| 20:45 |
|
prologic |
pretty much |
| 20:45 |
|
prologic |
meaning I'd buy each and every friend/family I want to have access a security device/key |
| 20:45 |
|
bear |
I often wondered about that |
| 20:45 |
|
prologic |
the idea here is that they would go thorugh an auth proxy (I'm still putting together) |
| 20:46 |
|
bear |
having a custom phone app that they can point the camera at the website, have it generate a token to send to the app then back it up with OTP |
| 20:46 |
|
prologic |
and asks for a username/password (something they know) and their U2F token (something they have) |
| 20:46 |
|
prologic |
the user/pass does not identify them though (shared cred) |
| 20:46 |
|
bear |
right |
| 20:47 |
|
prologic |
then on the app side internally behind the authproxy I was going to use CAS for SSO and AAAA |
| 20:47 |
|
prologic |
err one too many A's :) |
| 20:47 |
|
prologic |
AAA |
| 20:47 |
|
bear |
:) |
| 20:47 |
|
prologic |
But I still want to write a checklist anyway to be sure I've ticked of all the right boxes |
| 20:47 |
|
prologic |
and it could be useful to others too :) |
| 20:48 |
|
bear |
indeed |
| 20:51 |
|
prologic |
TLS/SSL, bcrypt/scrypt password storage, secure session cookie (httponly, maxage:0 etc), track login failures and increase cost (brute force), XSS/CSRF (I think XSS is moot if you have no JS?), regenerate sessions periodically, expire old sessions, OTP/U2F (disable if behind an authproxy that has U2F/OTP already) |
| 20:51 |
|
prologic |
(some things you said also) |
| 20:51 |
|
bear |
i've also been fond of this google site for PWAs -- https://developers.google.com/web/progressive-web-apps/checklist |
| 20:51 |
|
bear |
yea, that list looks sane |
| 20:52 |
|
prologic |
Ahh this is a nice list by the looks |
| 20:52 |
|
bear |
XSS can be moot if you don't have js on the frontend, but the backend may still get caught if it's validation library is js friendly |
| 20:52 |
|
prologic |
will need to study it more |
| 20:52 |
|
prologic |
maybe we can incorporate this or reference it as well |
| 20:52 |
|
bear |
always good to make footnotes to other sources of an item on the checklist |
| 20:53 |
|
prologic |
*nods* |
| 20:53 |
|
prologic |
yeah re XSS/CSRF I thin the important missing item there is to validate and escape all inputs |
| 20:53 |
|
prologic |
or more generally do not trust any inputs |
| 20:53 |
|
bear |
yep |
| 20:54 |
|
bear |
filter *every* field entering the system, whether it's from a client or the api |
| 20:54 |
|
prologic |
for API security (if you're building an API) I think there's some things like HMAC based auth over Basic Auth + SSL |
| 20:54 |
|
prologic |
I think its a lot simpler for APIs |
| 20:55 |
|
prologic |
what else are we missing? :) |
| 20:56 |
|
bear |
encryption at rest? |
| 20:56 |
|
prologic |
I'm going to put this together today I think and share it and we can improve it -- An idea I had was to use GH flavoured Markdown checklists and encourage developers that find this list to fork it and use it as their own checklist |
| 20:56 |
|
bear |
+1 |
| 20:56 |
|
prologic |
isn't that covered by TLS/SSL? |
| 20:56 |
|
prologic |
that should be the first thing to check off in both cases |
| 20:56 |
|
bear |
no |
| 20:56 |
|
prologic |
something else? |
| 20:57 |
|
bear |
your sending data to a web server, but what happens when it's stored to disk |
| 20:57 |
|
prologic |
Oh I see |
| 20:57 |
|
bear |
so unless your tokens and keys are in ephermal store, they will touch the disk |
| 20:58 |
|
prologic |
so for API key management, if persisting to disk (why would you not?) use bcrypt/scrypt? |
| 20:58 |
|
bear |
yes |
| 20:58 |
|
prologic |
in both api/app cases this is all to prevent an attacked from strealing your db and doing brute force against it |
| 20:59 |
|
bear |
there are fancier items, but basically make so you can't crack the whole system by doing a `cat /var/lib/session.dat` or some such |
| 20:59 |
|
bear |
right |
| 21:00 |
|
bear |
and if your really paranoid you make it so the app only unseals when a password is entered at startup (which uses 2factor and all that) |
| 21:00 |
|
prologic |
for Apps; SSL/TLS + regenerating session ids, epiring old sessions and maybe also using a session id + rotating token/serial -- preventing session hijacking (plus optionally XSS/CSRF depending if you have frontend JS) |
| 21:00 |
|
bear |
+1 |
| 21:00 |
|
bear |
it all depends on how far down the security turtle stack you want to go |
| 21:00 |
|
prologic |
oh yes! |
| 21:01 |
|
bear |
most stop at requiring unsealing of apps and assume that if the attacker gets root, it's all over |
| 21:01 |
|
prologic |
I love it -- provide decryption of stored keys/passwords/etc and verify with OTP :) |
| 21:01 |
|
prologic |
brb my daughter spilled my coffee on me :) |
| 21:01 |
|
bear |
and another layer of paranoia would require multiple different unseal keys |
| 21:01 |
|
bear |
haha |
| 21:16 |
|
prologic |
https://gist.github.com/prologic/04c2a642ca33a2f205540510499d4ac5 |
| 21:16 |
|
prologic |
started :) |
| 21:18 |
|
pdurbin |
prologic: recommended libraries for which language? |
| 21:28 |
|
prologic |
Yeah not sure yet |
| 21:28 |
|
prologic |
It would be nice to have a section on a set of recommended libraries per language |
| 21:29 |
|
prologic |
I'm hesitant to recommend "frameworks" because its much more difficult to audit/vouch for the security of a framework and all of the things it may or may not cover or get right |
| 21:29 |
|
prologic |
bear: pdurbin please help me by contributing to this draft gist :D |
| 21:31 |
|
pdurbin |
Per language sounds good. I'm glad you're keeping it agnostic. |
| 21:34 |
|
prologic |
trying to |
| 21:42 |
|
bear |
I forked it but how do I get my changes over to you? |
| 21:48 |
|
prologic |
I have no idea |
| 21:48 |
|
prologic |
these are backed by git itself -- maybe pull-requests are possible? |
| 21:49 |
|
prologic |
Ahh |
| 21:49 |
|
prologic |
git gist.github.com:04c2a642ca33a2f205540510499d4ac5.git |
| 21:49 |
|
prologic |
It can be cloned |
| 21:49 |
|
prologic |
Or alternatively I can make this a proper GH repo? |
| 21:49 |
|
prologic |
that might be easier? |
| 21:49 |
|
prologic |
Let's just do that instead (like what the awesome-self-hosted, awesome-... README repos are doing) |
| 21:52 |
|
prologic |
https://github.com/prologic/web-security-checklist |
| 21:53 |
|
prologic |
Let's use this :D |
| 22:41 |
|
pdurbin |
prologic: I just shared that repo with the security folks at http://www.abcd.harvard.edu who might have some ideas. |
| 22:42 |
|
pdurbin |
I absolutely love how it's described as "a community-driven curated web security checklist for the paranoid and impatient web developer". :) |
| 22:43 |
|
prologic |
Thank you :D |
| 22:43 |
|
prologic |
I wanted to start this out of my own selfishness :) |
| 22:44 |
|
prologic |
because of what I'm trying to do here internally at home for friends/family I had to start digging into this stuff a LOT more than I wanted to |
| 22:44 |
|
prologic |
who knew this stuff was so hard and complicated :) |
| 22:48 |
|
pdurbin |
prologic: sure. You could also post it on http://or8.net/mailman/listinfo/codecraft |
| 22:51 |
|
prologic |
Ahh ml's Oi'm not on :) |
| 22:51 |
|
prologic |
I've sortof/moreorless give up on being on mailing lists |
| 22:52 |
|
prologic |
mostly because I think I just can't keep up (very slow at reading given my poor sight) |
| 22:52 |
|
prologic |
if you're on it can you post on my behalf? :) |
| 22:53 |
|
prologic |
above all I would love for this checklist to be as well curated as possible, vetted by as many experts in the field (of which I'm not) and developer focused/friendly (hence the impatient part) |
| 22:53 |
|
prologic |
I don't need to know how KDFS works to benefit from using scrypt :) |
| 23:16 |
|
|
pdurbin_m joined #sourcefu |
| 23:16 |
|
pdurbin_m |
prologic: done: http://or8.net/pipermail/codecraft/2017-July/000206.html |
| 23:22 |
|
prologic |
sweet (y) |
| 23:35 |
|
prologic |
wee |
| 23:35 |
|
prologic |
I'm getting contributors already! |
| 23:35 |
|
prologic |
two so far :) |
| 23:35 |
|
prologic |
this is awesome! |
