Suppose you are a third-year university student studying information technology. In that case, you’ve been learning a variety of topics linked to computers in general up until now (programming, algorithms, computer architecture, math, etc.).

You are sure that no one can learn everything about Security. Still, every programmer or IT student should have a “minimum” level of information, and the question is, what that minimum level of knowledge is.

Keep the following ideas in mind if you want your applications to be safe and protected:

• Never place your trust in anyone’s advice!
• Use safelists instead of blocklists to validate the information from all untrustworthy sources.
• Plan for Security from the beginning; it’s not something that can be added later.
• Keep things simple since complexity raises the chances of security flaws.
• Keep your assault surface as small as possible.
• Make sure you fail safely.
• Use a multi-layered defense.
• Remember the principle of least privilege.
• Make use of threat modeling.
• Divide your system into compartments so that it isn’t all or nothing.
• It’s difficult to keep secrets buried, and secrets hidden in code won’t last long.
• Do not create your cryptography.
• Using crypto does not imply that you are safe (attackers will look for a weaker link)
• Understand what buffer overflows are and how to avoid them.

Some fantastic books and articles about keeping your applications secure are available on the Internet. Here are some of the helpful books:

• In addition, every programmer should read the second edition of Writing Secure Code.
• Building Secure Software: A Step-by-Step Guide to Avoiding Security Issues
• Cookbook for Secure Programming
• Software Exploitation
• Security Engineering is a fantastic book to read.
• HOWTO on Secure Programming for Linux and Unix

You can also educate your developers on the best practices for application security through the following:

• Codebashing is a term that refers to the act of (paid)
• Innovation in Security (paid)
• Compass of Safety (paid)
• WebGoat is an OWASP project (free)

The first rule of Security for programmers is not to use your own

Use a security platform, framework, or library that is well-designed, well-tested, and mature to handle the work for you unless you are a security specialist or cryptographer. Experts and hackers alike have spent years thinking about, patching, updating, and examining these items. You want to capitalize on those advantages rather than squandering them by attempting to invent something new.

That isn’t to suggest that you don’t need to understand Security. However, you must have sufficient knowledge to know what you’re doing and ensure that the tools are correctly used.

Make a turn back and halt for a moment, and recall the first rule if you ever find yourself about to start developing your cryptographic algorithm, authentication system, input sanitizer, or anything else.

Exploit code is something that every programmer should be able to develop. You unintentionally prevent vulnerabilities if you do not understand how systems are attacked. It’s pointless to know how to patch code if you don’t test your patches. Security isn’t just a series of thought experiments; it’s also about being scientific and putting your theories to the test.

Most Dangerous Programming Errors (CWE/SANS)

The CWE/SANS most dangerous programming list for 2010 faults compilation of the most common and essential programming errors resulting in serious software flaws. They are frequently easy to locate and exploit. They are problematic because they often let attackers gain complete control of software, steal data, or prevent it from functioning.

This list is a tool for education and awareness that aims to assist programmers in avoiding the types of vulnerabilities that plague the software industry by detecting and preventing all-too-common errors that occur before the software is even released. Customers of software can use the same list to ask for more secure software. Software security researchers can use the list to focus on a small but essential subset of all known security flaws. Finally, software managers with CIOs can use the list to benchmark progress in their software security efforts.

MIT Course

The MIT course on Computer Networks and Security would be an excellent place to start. One thing recommended is that you do not overlook the importance of privacy. Privacy is fundamental to Security in specific ways, although rarely addressed in technical security courses. For example, this course on ethics and law akin to the Internet may have private information.

Secure Defaults In Frameworks And Apis Are Critical

Many early web frameworks did not automatically escape HTML in templates, resulting in XSS issues.

Many early online frameworks made concatenating SQL easier than creating parameterized queries, resulting in a slew of SQL injection problems.

Some Erlang versions (R13B, perhaps others) don’t check SSL peer certificates by default, and there’s a good chance that a lot of Erlang code is vulnerable to SSL MITM attacks.

By default, the XSLT transformer in Java permits the execution of any Java code. Unfortunately, this has resulted in a slew of significant security flaws.

By default, Java’s XML parsing APIs allow the parsed document to read any file on the filesystem.

Three A’s

The three A’s are essential to understand. Authentication, authorization, and auditing are the three steps in the authentication, authorization, and auditing process. Diaspora’s mistake was to authenticate a user without checking if the person is authorized to execute any action, allowing the user to view other users’ private images. Many more people overlook auditing; you must determine who did what and when in a safe system.

Remember that while you (the programmer) are responsible for securing all components, the attacker only needs to locate one kink in your armor.

An excellent example of “unknown unknowns” is Security. Unfortunately, you may not always be aware of potential security issues (until afterward).

The attacker’s intelligence determines the difference between a bug and a security hole.

Recognize how different attack vectors operate; you can recognize them through the following:

• Buffer overflows, underflows, and other issues in native code
• Engineering social behavior
• Spoofing of the DNS
• Man-in-the-Middle 
• CSRF/XSS and others
• Injection of SQL
• Attacks on cryptography (ex: exploiting weak crypto algorithms such as DES)
• Errors in programs or frameworks (for example, Github’s latest security issue)

You can promptly look up all of this information using Google. This will provide you with a strong foundation. In addition, a project named Google Gruyere shows you how to exploit a working web app if you want to see web app vulnerabilities.

When it comes to establishing a business or developing your software, think like a hacker. As you all know, hackers aren’t experts in everything, but when they discover a vulnerability, they begin delving into it by gathering information on everything before attacking our program. So, to avoid such attacks, you need to follow several well-known guidelines, such as:

Always make an effort to crack your codes (use cheatsheets & google the things for more pieces of information).

In your programming field, stay up to current on security issues.

Also, as previously said, never place your reliance on any form of user or automated input.

Would you mind taking advantage of open-source software (their most security flaws are known and solved)?

More security resources can be found at the following websites:

• OWASP protection
• CERT (Certified Ethical Trading Environment)
• SANS (Security Awareness Network)
• Netcraft
• SecuritySpace
• Openwall
• Sec PHP
• Hackernews.com (keep updating yourself)

Google, your application vendor’s Security, flows for more information. Bruce Schneier is a great resource as well for general security information. He has a website, a crypto-gram newsletter, many publications, and numerous interviews under his belt. Furthermore, Cliff Stoll’s outstanding (if a little dated) book “The Cuckoo’s Egg” is a good (and quite entertaining) book on how Security plays out in the real world.

Check out the OWASP Top 10 List to break down all the primary attack vectors and vulnerabilities. It’s fascinating to learn about these topics. In addition, learning to think like an attacker will help you think about what to consider when building your code.