Some folks have advocated that security should be integrated into computer science coursework, throughout the curriculum. Suppose we are going to add one lecture on security, to a first course on programming. (Keep in mind that it is a very basic introductory course, so advanced topics are not appropriate.) What are the most important things that students should learn about security, in that context?

I think they should just add in safer programming tactics for someone who is just dabbling in it, to protect from simple things like buffer overflows. Then, if the student still shows an interest, the security can go more into depth. But that's just me =p
–
ekajMar 16 '12 at 16:39

5 Answers
5

If this is only going to be one lecture and this is their first programming class, I think input validation is the most viable topic to go over. Some of your students will already be struggling to understand how x = x + 1 (x equals x + 1) when x = 1 just the line before ... that is until they realize that it is an assignment statement.

Topics such as encryption, ssl, and sql injection need to be integrated in courses that have related projects so that they can be practically applied.

Input validation, however, is something that they will carry with them for the rest of their engineering career. It will help them mitigate the chances of their code being susceptible to buffer overflows, XSS, and (maybe)sql injection.

Security education should be contextual. There's not a lot to say about security when you're studying red-black trees or merge sort. But security should be a constant and pervasive factor as part of everything the student does.

Any security-related items should be required as a matter of course; bounds-checking and input sanitization, for example, should be absolutely required in all assignments. If the examiner can break the homework application by supplying invalid input, then points should be deducted. If array bounds aren't properly checked (assuming an unsafe language like C), then points off. It should't be sufficient to just have the thing pass the assigned test-case, it also has to be well-enough written that in a real-world scenario it wouldn't cause a disaster.

The students need to be used to always worrying about robustness and security the same way that chemistry students always should be worrying about lab safety. Security isn't something you study one semester and then move on.

If you're going to have a single lecture at the beginning about security, then it should primarily cover the security-related expectations that the students will be under. These expectations should be real-world expectations with respect to coding practices and should reflect the sort of vigilance that is always in the back of the mind for a good programmer.

This breaks down into several main areas, not all of which are appropriate for every language and every programming environment, here are a few that come to mind:

Language safety: An extremely big deal with C/C++, not so much with most everything else. Pointers, buffers, and that sort of thing fall into this category.

Input sanitization: Huge. Absolutely huge. I can't think of a single area in which this is not applicable.

Code clarity and documentation: Worth more than it sounds like. Many security vulnerabilities come from simple mistakes which stem from a misunderstanding of the code itself. The fewer mistakes you make, the better, even in the context of security.

Also, I'd throw in principles like "DRY" into this mix, since security vulnerabilities sometimes are the result of assumptions being out-of-sync within the code. The more places you specify a single value, the more likely you'll forget to change one of them, which can lead to security vulnerabilities. I remember a "no magic numbers" homework rule when I studied CS, where all numeric constants had to be assigned a name. It's a good policy to have for many reasons.

Privilege isolation: A bit more esoteric, but important in certain scenarios. The principle of least privilege is something that students need to at least be familiar with, for example; but it's difficult to make part of your day-to-day activity.

Security-specific items: Such as password storage, encryption, and stuff like that. This is more informational than directly applicable with respect to schoolwork, so I'm not sure where it fits in with respect to lesson scheduling.

It's important to learn about attacks like CSRF and token-stealing
attacks in the more abstract sense, but probably not in an
introductory course since it's a little advanced.

Im college student and I had that kind of course, first of they should teach how not to make mistakes in coding I mean, like protection against SQL Injection, or teach how to make own SSL connection and authorization, and a little about cryptology, I had like 7 sessions of that and all topics were explained pretty good... (I mean those topics weren`t just basics...)
Now in my opinion there should be a lesson about how to protect against sql injection, and some stuff about cryptology like program called PARI..., those should be basic