greptilian logo

IRC log for #sourcefu, 2017-07-29

http://sourcefu.com

| Channels | #sourcefu index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

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:04c2a642ca‚Äč33a2f205540510499d4ac5.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!

| Channels | #sourcefu index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

http://sourcefu.com