[ / / / / / / / / / ] [ dir / ask / dcaco / fur / hypno / o / sl / ttgg / u ][Options][ watchlist ]

/prog/ - Programming

Programming board

Catalog

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 1442040142588.jpg (1.98 MB, 2456x3205, 2456:3205, xakepy.jpg) (h) (u)

[–]

3e0999 (4) No.3244[Watch Thread][Show All Posts]

Most startups, and even gigantic corps have little or no actual security people to test software. It's just a factory where you churn out features and nobody is doing any checking, they work with C libraries with abstracted shit like angular/coffeescript/javascript and don't do proper testing or even best practices. If you learn how to write tests yourself, then you basically create your own CSIO role and parachute yourself into it. Remote CSIO is pretty easy, you just load up Emacs and use plugins like HiLock to quickly search through code, and org-mode to bookmark code you spot is obviously flawed or with to test later. You write your recommendations then go back to the beach in Thailand or w/e you work out of.

Start with

How to Design Program (HtDP)

it focuses on sane design and running tests in Racket (Scheme). The MOOC for it on edX is free, payment only for certificate of completion https://www.edx.org/xseries/systematic-program-design-0

At first it feels like rote learning, you are writing all these templates for seemingly simple functions. Trust me, it makes sense later on in the course/book when the programs become huge. You can slide right into Typed Racket after just a few chapters in https://www.classes.cs.uchicago.edu/archive/2014/fall/15100-1/guide.html

Do the rest of the course in Typed Racket to learn about type safety and you'll see for yourself how it works when you fail tests accidentally.

Now you need to write your own security tests, to start breaking non typed software using your knowledge of how stuff can break from creating type safe software. Read Gray Hat Python http://libgen.io/book/index.php?md5=381ABC536B480375ED49608177BB54E3

It specifically teaches you how to write security tests. If you've never used Python (after doing HtDP course) then read Zed Shaw's Python the Hard way tutorial which you will zoom through if already done HtDP http://learnpythonthehardway.org/book/ and/or Violent Python http://libgen.io/book/index.php?md5=eae478007e8e105aed06876890dfdf3d

Now get and read the following books:

Learn C the Hard Way http://c.learncodethehardway.org/book/

Secure Coding in C and C++ (2nd Edition)

The Art of Software Security Assessment

Zed Shaw's C tutorial has you breaking shitty code in the 4th lesson. The other books are still the defacto guides to secure development. It doesn't matter that they are C related, since the vast majority of errors apply to every program regardless of language. Whenever you come across a problem in the software assessment books, write a test for it and apply it to the software you maintain/build. If it fails, congrats you just saved whoever you work for countless money should anybody exploit that later.

Now go on HN (Hacker News https://news.ycombinator.com/news) and search for Unit Testing, Regression Testing, Fuzzing, and Security Tests. Write some of your own using their examples and apply them to where you work. If they don't parachute you into CSIO by now then nobody else will ever get that job. I guarantee you will break absolutely everything just doing basic tests unless you're using type safe languages from the start, which is hardly any company right now.

Other helpful books:

The Mobile Application Hacker's Handbook

The Web Application Hacker's Handbook

The Tangled Web: A Guide to Securing Modern Web Applications

The Android Hacker's Handbook

Yes, webdev shit but everything is networked, everybody runs a browser, every app has an API, ect. Again, everything you learn from those books write tests for them in your software suite (by now, your suite is so large you could probably sell or license it).

continued next post(s)

3e0999 (4) No.3245>>3246

So you applied to some generic, devops or other remote job and have written tests for their software, broken it repeatedly and used advice from TASSA how to fix it, or rewritten the entire application in a type safe language. They've appointed you to remote CSIO with 2x salary so now what do you do. Here's some HN advice:

Plan to update your platform software at inconvenient times. Dry-run your update process, so you know it will work on no notice. Avoid your OS's packaged versions of things like nginx; having a known-working source build gives you control of when and how you'll apply patches

Put someone on your team in charge of tracking your dependencies (C libraries, Ruby gems, Python easy_install thingies) and have a process by which you periodically check to make sure you're capturing upstream security fixes. You should run your service aware of the fact that major vulnerabilities in third-party library code are often fixed without fanfare or advisories; when maintainers don't know exactly who's affected how, the whole announcement might happen in a git commit.

Use TLS to encrypt data in motion and use GPG to encrypt data at rest, and don't do any other kind of crypto. Getting custom crypto right is impossible unless you are DJ Bernstein or Neils Ferguson. If you must do custom crypto work look at NaCl (or libsodium) which is a black box of crypto functions.

Stay on your platform's "golden path" for web security issues. Rails developers should default-whitelist ActiveRecord models, enable CSRF protection, and avoid "html_safe-ing" strings so that the maximum amount of code inherits default protections against mass assignment, XSS, and CSRF. Anything you customize will probably bite you in the ass. Keep your code boring.

Triple check any piece of code that "shells out" to command line tools. By "triple check": have a process by which three signoffs are required to merge any such code into the deployment branch.

Be extraordinarily wary of library code for web apps that includes "native" C/C++ code. Very popular C library code for modern web platforms has been found susceptible to basic memory corruption issues, because the kinds of people that look for memory corruption bugs don't usually think to troll Github for Ruby, Python, and PHP code with native backend code; terrible bugs can thus stay latent for years in code you can point a URL to and read.

People will hate me for saying this but I'm here to offer honest advice: prefer almost any modern language to PHP or Perl. I don't know what to tell you other than that PHP and Perl apps fare worse on security assessments than everything else.

I have more than once recommended that people who are very very concerned about platform security (ie, about the likelihood that there are memory corruption bugs in their language stack) use JVM languages.

Do your admin stuff out-of-band. Write a separate admin app (bonus: the admin app can look shitty, and so is less expensive to maintain) that requires a VPN connection to access. Avoid special-privilege accounts in your normal apps. From years and years of experience working with startups: this is something you will mess up on.

Triple-check code that handles direct file uploads and downloads. The filesystem introduces a new namespace, so upload/download code needs to juggle different privilege and authorization domains to handle it. We see fewer problems at companies that dump blobs with opaque names into S3 than we do with apps that have a file repository with named files.

continued


3e0999 (4) No.3246>>3247

>>3245

HAVE A SECURITY PAGE FOR YOUR SOFTWARE. Have that page very cordially invite people to submit security flaws to an email address at your site; provide a PGP key for it. If I was maintaining a commercial app, I'd put a phone number on that page too. If you don't have this page, you should know that you are tacitly inviting people to report security flaws to Twitter.

If you use some shit cloud server like AWS (everybody does) then partition your accounts(s) so that if one is compromised everything isn't compromised. https://news.ycombinator.com/item?id=10024958

If worried about a social engineering attack where somebody calls your host and asks them to reboot the server pretending to be you (like what happened to bitcointalk forums) encrypt your disks (FDE). They'll need a password to continue booting from the serial/remote console.

If anybody in the corp uses botnet like Gmail then disable all phone 2factor password reset to prevent spoofed SMS from hijacking accounts (and later holding them for ransom, this happens all the time). Preferably don't even use botnet and instead use posteo.de which is FSF recommended.

If you have a proprietary firewall ditch it in exchange for OpenBSD https://www.nostarch.com/pf3 all cisco and juniperOS junk is open to exploitation and out of your control.

If working with C libraries wrap your libraries up in ADT-style interfaces. Give every such interface a _create() and a _destroy() method. Have _destroy() either return a pointer (which will always be NULL), or (better, I think) take a pointer-to-pointer so that it can zero the pointer out after destroying the object.

Don't check malloc; instead, rig your code up to detonate if malloc ever fails. Checked allocations create rats nests of error handling.

Have a common hash table, a common binary tree, and a common list or resizable array, working on void-star. Don't allow programmers do implement their own hash table or tree. Have a common logging library, with debug levels.

Any other advice post here


3e0999 (4) No.3247

>>3246

also… note, this is just basic, bare minimum competency in software security but you'll quickly realize in the "industry" that nobody is doing it.

start following competent appsec developers like this guy http://sakurity.com/blog and google's project 0 blog to learn more http://googleprojectzero.blogspot.ca/ and follow arxiv http://arxiv.org/list/cs.CR/recent#

usenix conferences are also great https://www.usenix.org/conference/usenixsecurity15/technical-sessions a bonus of being CSIO is they fly you to them for free.

nb


079bd7 (1) No.3259>>4582

Question:

If I use parameterized queries for every query that isn't hardcoded, am I 100% safe from SQLI?


418e34 (1) No.4581

I need to use clusters for research. What services other than AWS or Azure do you know?


438f2f (1) No.4582

>>3259

Front-End validation




[Return][Go to top][Catalog][Screencap][Update] ( Scroll to new posts) ( Auto) 5
6 replies | 0 images | 4 UIDs | Page ?
[Post a Reply]
[ / / / / / / / / / ] [ dir / ask / dcaco / fur / hypno / o / sl / ttgg / u ][ watchlist ]