[ale] Be careful where you learn to code

[DJ-Pfulio]

On 04/21/2017 11:08 AM, Jeremy T. Bouse wrote:
> On 4/21/2017 10:52 AM, leam hall wrote:
>> On Fri, Apr 21, 2017 at 10:40 AM, Alex Carver <agcarver+ale at acarver.net
>> <mailto:agcarver+ale at acarver.net>> wrote:
>>
>>     On 2017-04-21 07:19, DJ-Pfulio wrote:
>>     > Be careful where you learn to code. Not all tutorials are equal,
>>     > especially for web-app scripted languages.
>>     >
>>     >
>>     https://www.helpnetsecurity.com/2017/04/21/programming-tutorials-vulnerabilities/
>>     <https://www.helpnetsecurity.com/2017/04/21/programming-tutorials-vulnerabilities/>
>>
>>     That MySQL example on the page is just awful.  I've seen some written
>>     this way but with large warning boxes below the example that explicitly
>>     say this method is insecure and only intended to show a process flow
>>     (checking against a count of users).
>>
>>     Doesn't matter the language, the basic concept of sanitizing user input
>>     should be universal whether by using sanitizing functions, stored
>>     procedures for DBs, casting or anything else.
>>
>>
>> An issue is that new coders need to not learn security until they learn the
>> basics, but they need to learn that security is important before they put code
>> into production. Very few code communities seem hyped about security as a
>> worthwhile learning path. I've been looking into it more for my own needs and
>> would happily take recommendations on more resources. Especially Ruby, not
>> Rails.   :)
>>
>> This from 2003:   http://shop.oreilly.com/product/9780596002428.do
>>
>> Video:    http://shop.oreilly.com/product/0636920047179.do
>>
>> OReilly site:   https://www.oreilly.com/topics/security
>>
>> Personally I'd recommed communities build mentorship programs. Security is
>> just one aspect of professional coder growth.
> 
> I think the problem is more systemic from my POV... Security has always been an
> afterthought for coders and usually only after a major vulnerability is
> exploited. Further to that, as I've seen far too often in the corporate space
> there is the push to get products out so corners (like security) are cut to
> increase deliverable with the promise "we'll go back and fix it later" but turns
> out that the those tech debts just keep building up and rarely if ever get
> worked on. This leads to bad code getting out there and then never being cleaned
> up. I've fought this battle in several jobs where I tried to get things done
> properly because I knew once it went out it wouldn't ever change and 9 times out
> of 10 that was precisely what happened. 

The demo verion becomes the production version. That is common.
Programmers might put a :TODO: or :BUG: tag in their code, but never have time
to go back and fix something they hacked together to meet a deadline.  I've been
there, done that.  Didn't worry about security until I was making the list of
things the next guy should handle on my way out the door.

OWASP has Top 10 lists for many languages. Their php one is good read. There is
a local chapter in ATL - next meeting is at FISV way up GA-400. There meeting
locations change, but are usually at nice corporate locations with free parking.

The Perl community **does care** about security.  If you follow their
recommendations, you'll end up with very fast AND secure code.  It is HARDER do
do it wrong when it comes to DB stuff than to go the recommended way with DBIx.
Plus, DBIx was always faster than my hand written SQL, if you count loading the
data into objects.

Perl has Perl::Tidy and a Best Practices code review system which parses code
and directly references paragraphs in the Perl Best Practices book. There's a
huge section just on regex - as you can imagine.  The perl guys fixed regex so
comments and multi-line regex are allowed.

I've worked a few places with a clear mentoring effort. We were using languages
that nobody else used, so there wasn't any other choice.  At one place, our
development team crafted "C++ coding standards" - just going over those was a
great way to teach/mentor newer developers. It also made for some heated
discussions, since everyone has a slightly different "coding style."  We ended
up using a code formatter that was used prior to check-in.  I thought this was
standard practice?

Coding standards aren't just about readability. They are about preventing code
errors as early in the cycle as possible.  We wrote defensive code. The goal was
for it to break at compile time, not runtime.  In comparisons, constants were
always placed on the LHS, not the RHS. This prevents the accidental assignments.
 We always used {} - even when they weren't needed - ALWAYS. We included module
entrance and exit debug macros. These could produce very detailed stack tracing,
if needed, on production systems by changing a setting in a file - no program
restart needed. Lots and lots of things like that. We didn't let developers on
any production systems.

Saw a "Secure C++ Standards" document a few days ago from a reputable company.
If anyone grabbed that link, please posting it here.

Sorry for the reply length.