[ale] Be careful where you learn to code

[Jeremy T. Bouse]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20170421/bab964b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4521 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.ale.org/pipermail/ale/attachments/20170421/bab964b9/attachment.p7s>