37

This might be far too narrow, but it is a unique problem to ITSec professionals. A loved one is just starting out in a new programming career and I get the joy of watching her learn the most basic programming concepts from scratch. She is at the top of her class in each of her college courses, producing high quality work, and she has attracted so much attention that she is already getting contract work.

As ITSec pros, we talk about infusing the development cycle with secure coding practices and design, but how does that apply to a brand-new learner? A new programmer is at the start of their own 'lifelong development cycle', at it were. At what point is it appropriate, from an educational perspective, to switch from the mindset of 'getting it to work' to 'it absolutely must be secure'? At what point should a student 'fail' an assignment because of a security issue?

She completely understands the need to produce secure code, and wants to, but none of her classes have introduced the idea and keeps coming to me for code review and analysis. When should the switch be made to force her to re-design all the class assignments to use secure design?

I don't want to cut a promising career short by introducing frustrating requirements, but I also want to give that new career the best possible start. In addition, are there resources to help me teach her the basics of secure coding from a beginning programmer's perspective? I find that I'm making it up as I go...

I welcome your advice.

  • At what point is it appropriate, from an educational perspective, to switch from the mindset of 'getting it to work' to 'it absolutely must be secure'?
  • At what point should a student 'fail' an assignment because of a security issue?
  • When should the switch be made to force her to re-design all the class assignments to use secure design?
  • Are there resources to help me teach her the basics of secure coding from a beginning programmer's perspective?

As a side note: I have noticed that by raising the bar in my code review of her class assignments, just in terms of basic 'validate and sanitize' security, she has ended up producing very high quality code in general. From this one example, I think I can see the value of starting one's education this way because it forces an even deeper understanding of data flow and programming logic.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 26
    Your question title makes the context sound really weird. You mention she's a loved one, yet the content sounds like you're her teacher. I mean, whatever floats your boat, but... O_o – Polynomial Dec 12 '12 at 16:07
  • 6
    She is a loved one and I am an educator, just not hers nor a programming instructor :) It's hard to ever take the 'educator' hat off, and she does keep coming to me for 'extra curricular' work :) – schroeder Dec 12 '12 at 16:17
  • 2
    Since 'it absolutely must be secure' is hardly (surely) achievable in practice, I wonder that's appropriate pedagogically. It would be better IMHO to point to literatures on risks in the internet. – Mok-Kong Shen Dec 12 '12 at 16:24
  • Simply pointing out that the flaws are there is the most important thing you can do in my opinion (i.e. instill critical thinking, and do it early). You don't need to tell her the specifics or even ask her to find them, but let her know that somewhere in that code..those nasty exploits are just waiting to be found – Arnab Datta Dec 14 '12 at 01:30
  • 7
    whats the difference between teaching programming to a "loved one" vs "anyone" – Midhat Dec 14 '12 at 09:24
  • 2
    @Midhat You have significantly more influence over a loved one in your interactions than you do some random person. – forest Dec 28 '17 at 09:28

6 Answers6

53

I would say a great way to learn is for her to break the applications she has already written.

Assuming she is writing web applications, point her towards the OWASP Top 10. Have her see if she can find any of those flaws in her own code. There is no better way to learn about security concepts than actually seeing it happen on your own code.

Once a flaw has been found, have her rewrite the application to fix the flaw. Doing so will allow her to appreciate the effect of things like sanitation and validation of user inputs and parameterized queries.

Take incremental steps. I wouldn't jump straight into designing a new application with security in mind before truly understanding what type of codes result in security flaws.

  • 2
    Agreed. Breaking my classmates assignments, and their doing the same to mine, in my highschool programming class was not only fun; but did more to show the importance of input sanitization than any formal instruction I had afterwards. – Dan Is Fiddling By Firelight Dec 12 '12 at 19:34
  • 3
    Yup! I did not know nothing about security in a web application until some attacker screw me a lot. SQL Injections, Remote code execution, filesystem traversal... all those security flaws were in my little web application. Boy, was I naive back then about clients always sending expected data... – Carlos Campderrós Dec 13 '12 at 08:41
17

I'm going to take the position that may get me flambéed...

The problem I see, is that secure programming is taught as an add on. Best practices should be taught from the beginning (including security). The lie people are taught is that practice makes prefect. The truth is practice makes permanent. So if you are doing it wrong, you have to unlearn what you have learned. That is a bassackwards approach.

I would say that secure coding practices should be taught from day one. There's no reason to learn how to do it, and then learn how to do it securely. It's a waste of time and money...

My 2 bits, 1, and zero more to say...

Everett
  • 1,506
  • 1
  • 12
  • 20
  • 4
    But then you would need to include all aspects of best practices from day one, and this would mean atleast 10+ aspects to worry about when someone hasn't even learnt programming. How is that even possible for most mere mortals? – Arnab Datta Dec 13 '12 at 00:07
  • 6
    @ArnabDatta Mere mortals shouldn't be programming. – AviD Dec 13 '12 at 08:58
  • 1
    I'm in uni at the moment, and secure coding is hardly mentioned. There is a separate module about it but this isn't compulsory... So when the other students who had only just started PHP (add any other language you wish) had had their assignments marked I went and showed them, look if I do this I have just destroyed your coursework... I didn't do this maliciously, and I only did it to friends, but they all went away and tried to fix the security holes. It was quite an eye opener for them – cosmorogers Dec 13 '12 at 14:45
  • 1
    I pretty much agree (and upvoted the questions) but I'd move to day two rather than day one. At the very beginning, it's too much effort for the novice programmer to just get something to work. Start, oh, about a third of the way through the first semester. – mpez0 Dec 14 '12 at 19:45
  • I agree with this answer. In 2017 security should be a core coding concept just as data persistence is. You don't need to overload new programmers with everything security, but new programmers should know how to transfer data between systems and secure data their app is exposing in accordance with best practices of today. New programmers can start off on a single system with all input coming from keyboard and all output going to screen or local disk so as to not complicate the learning curve of the language and programming. – Thomas Carlisle Dec 28 '17 at 15:25
13

While I agree in principle with Everett, there is another point of view. The point of a lesson is to learn a concept, which can then be further built on. This lessens the slope of the learning curve. Teaching too much too fast is overwhelming; when faced with an onslaught of information, most brains "leak".

It's great to say "Secure coding practices should be taught from day one", and very hard to demonstrate how that day-one "Hello World" program may be vulnerable, especially when "what is a computer program" is a new concept for the class. A website project touching shared data stores (which I didn't really see till at least halfway through college) is easier to show weaknesses in, but often those weaknesses are inherent in setting up a basic proof-of-concept web environment with the "default" settings. It's very easy to prove an application has vulnerabilities, when the vulnerabilities are known. It's harder (impossible, really) to prove none exist.

I think similarly to the OP; at some point in the development of a programmer, the idea of "how could someone use this code to do things you don't want them to do, and how can you prevent it" can be merged into what you're doing. That starting point is probably somewhere around beginning to learn either about external communication or persistence (reading/writing data to a hard drive or database, or sending it across a network channel), or the object-oriented principles (inheritance, overloading/overriding, etc), whichever comes first. This is where a coder can begin to write programs that have the power to do damage in the wrong hands, and thus care should be taken to ensure the wrong hands are not able to misuse the program.

Some concepts are easy to grasp; "My program works with data that is a secret of its users; I am trusted with it and must ensure that only those who should see the data are allowed to". Some are harder; I've seen people who are genuinely shocked to discover that program binaries can be decompiled and read to discover hardcoded credentials or keys (and that some environments like .NET put enough metadata into the binaries to produce almost exactly the same source code used to build them), or that their assembled binary can be piggybacked on in its compiled form by an attacker who plugs in using public unsealed classes or members, and then has access to any secrets those classes work with. These are the basic gotchas that should be illustrated, and then solutions to them should be illustrated, and how and why they work explained.

KeithS
  • 6,678
  • 1
  • 22
  • 38
  • 3
    You can always start with awareness. I think it would look something like this: Okay, we've finished "Hello World." Can anyone think of a way to make this program do something it wasn't designed to do?" The likely answer will be no, and that's okay at this level. But at least ask the question. Bring forward that it is a consideration. Start the dialogue. Waiting until year three to say, "okay, you've learned all these coding techniques, now we're going to show you how vulnerable your crutches are," is bad form... isn't it? – Everett Dec 12 '12 at 20:06
  • Agreed, to a point. It took a solid year and a half for my high school C++ class to advance to a point where programs had enough power over the systems they ran on to actually be security vulnerabilities, and it wasn't until halfway through college that I began writing code that in a real-world context would have been publicly exposed (and would thus be more self-dependent for its security against attacks, as opposed to an intranet site or local thick client primarily dependent on a competent sysadmin). – KeithS Dec 12 '12 at 21:04
  • You may not be able to teach security programming on day one, but a reasonable "day two" program may well be suitable: how does your number-guessing program react when you guess the number "q"? How does your repeat "Hello" printer react when you ask it to print "Hello" -3 times? As soon as you introduce the concept of input, you can start talking about input sanitization. – Mark Feb 09 '18 at 08:09
9

Much like other aspects of a real education (perhaps this should be more on Parenting.SE...), I think it comes back to critical thinking.

My daughter is also taking some college CS courses, and I'm helping her work through them. However, I do not spoonfeed her the information, she needs to work for it.
In many cases, I explain something very wrong to her, and expect her to call me on it. (She usually does). Sometimes, it's only subtly wrong, and then it's harder for her to notice. Sometimes she doesn't notice it right away, and starts building something based on a wrong assumption - then she has to work backwards to find the problem. (She is getting better at that, too.)

In this way, I force her to get used to questioning assumptions.
She is admittedly not thrilled about my methods.

In the same way, I ask her to spot any way that her code could be misused, either accidentally or maliciously. I explained to her that She owns her code and is responsible for what her code does, no room for passiveness here. Part of this is proper exception handling, which her instructors expect them to do anyway, even without really getting into it until much later courses.

Now, of course, I oppose all forms of teaching "cargo cult programming" - unless it is explicitly noted as such, to enable the basic concepts to be taught, with the caveat that it is not the whole story and we will come back to this later. (Such as the above exception handling).

My point from all this is that "secure programming" is no different from "programming".
However, just as the entire Book of Programming cannot be taught in a single sitting all at once, but concepts are introduced gradually - the "security" aspects of the programming concepts could wait, while the basic concept is taught and understood, with the explicit note that "we're not done here yet". Also the expectation that at least the better students would figure out some of the insecure aspects.

TL;DR:

  1. A new programming concept needs to be learned gradually, some aspects (including security) can be taught later than others;
  2. Said programming concept is not complete until all aspects are learned and understood, including security aspects (and should be noted until then);
  3. Programmers have complete contol over their code, and to be a programmer one needs to know how one's code can be misused;
  4. Students that practice critical thinking should be figuring this out by themselves early on (not necessarily all of security, but the missing context, and a good part of code misuse);
  5. Students that do not practice critical thinking shouldnt really be learning programming....
AviD
  • 72,138
  • 22
  • 136
  • 218
  • +1 for 'cargo cult programming' and point #5. I wish more of her instructors would lead her down the primrose path to expose problems with certain approaches. I cannot do exactly what you do with your daughter, but your approach reminded me to keep finding a way to use that somehow. – schroeder Dec 13 '12 at 15:22
5

I think that ultimately it comes down to trying to figure out at what point the security education doesn't obfuscate the point of the lesson. Lesson assignments are usually simplified problems designed to expose a particular problem and show how to solve that particular problem.

I think the more ideal way to approach it is to start out with having her do something like hackthissite.org to learn how many attacks work and what the dangers are. Having a healthy appreciation of how code can be subverted is a great way to help someone understand the importance of secure coding practices. Doing it in parallel means it won't obfuscate the topics her instructors are trying to get at while also showing what security concerns are.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • I thought of your parallel approach, but wondered how to bridge the gap in order to implement proper coding from the start of a new project. I think I have covered the basics (validate and sanitize), but I want to reach the next step: basic design. – schroeder Dec 12 '12 at 16:32
  • I'd say probably approach it as a unique project. Maybe even take one of her more complex projects that has holes in it and use that to compare the difficulty of going back and retrofitting security versus having good security from the start. Hard to say without seeing the actual projects you have to choose from though. I know for me, just being familiar and comfortable with the attacks was enough to make me build my designs to compensate, but then again, I've also been coding since I was 5... – AJ Henderson Dec 12 '12 at 16:35
1

From my point of view, as a systems analyst, there is a way - you should teach first graders a concept of standartization, classification and pattern matching. Following questions are easy, and could be brought at the very start...

  • Think about "all possible data input", that user can input, and create a strict list of them.
  • Learn/teach Regular expressions. This tool can be used either for matching and sanitization.
  • Principle of "default values", if input data is missing or invalid.
  • Use log files. If there is any doubt or inconsistency of input, software should use some sort of logging, to "write that down". Log files is one of best ways to debug and find out security holes, that someone could use or is already using.
  • Use error messages and error cases. Think of cases, when system could fail and think of appropriate error number and verbose message. Some errors could lead to two different verbose error messages - one for user, plain and simple, one for owner of system - for debug or security purposes.

User is always "bad guy", user always wants to break your software - never give user more information, than he asks for, and if he is asking, always check, if he is priviliged to receive even an answer of simple "You have no access" - error messages can help hacker to understand the state of the system, he is trying to break.

Could think of more, but this can and should be tought from early on.

Deele
  • 263
  • 2
  • 10
  • 1
    I would love to see research on the success of teaching regex to 1st graders. If it can be done, it would solve so many cognitive issues as they grow up .... – schroeder Dec 13 '12 at 15:24
  • @schroeder Personally, I started with Ben Forta's little book http://www.forta.com/books/0672325667/ translated in russian. But, I guess, most professors/teachers doesn't understand regex by themselves, that is why they are not teaching it. – Deele Dec 13 '12 at 18:24