This is a mirror of official site:

Defend Your Code with Top Ten Security Tips Every Developer Must Know

| Monday, July 30, 2012
Security is a multidimensional issue. Security risks can come from anywhere. You could write bad error handling code or be too generous with permissions. You could forget what services are running on your server. You could accept all user input.

1. Trust User Input at Your Own Peril

2. Protect Against Buffer Overruns

3. Prevent Cross-site Scripting

4. Don't Require sa Permissions

5. Watch that Crypto Code!

6. Reduce Your Attack Profile

7. Employ the Principle of Least Privilege

8. Pay Attention to Failure Modes

9.Impersonation is Fragile

10. Write Apps that Non-admins Can Actually Use


1.     Trust User Input at Your Own Peril

Always remember one thing: "don't trust user input." If you always assume that data is well formed and good, then your troubles are about to begin. Most security vulnerabilities revolve around
the attacker providing malformed data to the server machine. Trusting that input is well formed can lead to buffer overruns, cross-site scripting attacks, SQL injection attacks, and more.

2. Protect Against Buffer Overruns

A buffer overrun occurs when the data provided by the attacker is bigger than what the application expects, and overflows into internal memory space. Buffer overruns are primarily a C/C++ issue. The overflow causes corruption of other data structures in memory, and this corruption can often lead to the attacker running malicious code. There are also buffer underflows and buffer overruns caused by array indexing mistakes, but they are less common. Take a look to the following source code example:

void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {

    char cBuffDest[32];



If the data comes from an untrusted source and has not been validated, then the attacker (the untrusted source) could easily make cBuffSrc larger than cBuffDest, and also set cbBuffSrc to be larger than cBuffDest. When memcpy copies the data into cBuffDest, the return address from DoSomething is clobbered because cBuffDest is next to the return address on the function's
stack frame, and the attacker makes the code perform malicious operations.

The way to fix this is to distrust user input and not to believe any data held in cBuffSrc and cbBuffSrc:

void DoSomething(char *cBuffSrc, DWORD cbBuffSrc) {

    const DWORD cbBuffDest = 32;

    char cBuffDest[cbBuffDest];

Read more: Sharing SharePoint
QR: Inline image 1

Posted via email from Jasper-net