Overview of security issues

The problem of ensuring the safety of websites to avoid attacks from bad guys is always a headache for website administrators and the programmers who create those websites. The number of vulnerabilities is increasing and the hacker level is also increasing, making the problem for website protection from hacker attacks more important than ever. Most security problems are related to programming errors. Although not a single programmer would expect his application to have security flaws, in reality, due to the complexity of the technical systems, the attention paid to the functionality was focused. application lead, to progress… ensuring the application is free from security flaws is extremely difficult, even for advanced programmers. In general, building secure software is much less expensive than fixing security issues after the software is complete, not to mention the possible costs associated with a security breach.

Realizing that problem, OWASP (OWASP is a global non-profit organization focused on improving the security of software, web applications) has provided a guide for programmers to implementing programming safely, avoiding serious security vulnerabilities: OWASP Secure Coding Practices Quick Reference Guide . The document was published in 2010 but up to now it is still valuable and highly applicable.

Secure Coding Practices Checklist

Input Validation

This requirement involves checking input data, developers need to make sure to check all input from the user and process or check them on the server side (not on the client side. ).

1. All input data should be handled in a safe, reliable system.

• The trusted system can be a server that we manage, and a third-party server that is reliable and secure enough.

2. Clearly define which data sources are reliable and unreliable. For untrusted data sources, you should do a test on the server before performing any other action.

• Trusted data sources: Processed data, data from previously known trusted sources (google, facebook ..)
• Unreliable data sources: User input, databases, file streams, …

3. It is recommended to perform centralized data testing for the application

• Performing centralized data audit minimizes resources and provides easy control over potential security issues. For example, all the data the user enters from the form will be centrally processed to clean it through a certain function or library to ensure all data will be processed before going to the next step.

4. Specify standard character sets for the input data (UTF-8) and perform data encoding to a standard encode before performing the test.

• This ensures the data is standardized before processing and helps to remove dangerous characters from the input data

5. Validation failure should be handled to always deny that input

• If the user enters invalid input, it should be discarded without further processing or storage and there is notice of invalid data entry so that the user knows.

6. Validate all customer-provided data prior to processing, including all parameters, URL and HTTP header content (eg cookie name and value).

• This test helps to avoid related vulnerabilities such as path traversal, open url redirection, server-side injection.

7. Verify that the header values ​​in both request and response contain only ASCII characters

• This helps to ensure that the input data contains only valid characters, avoiding vulnerabilities related to: host-header injection.

8. Authentication of data from the redirect (Attacker can send malicious content directly to the target, so the hacker can circumvent the application logic and any authentication performed before the redirect)

• Usually the website has functions that allow users to redirect to other websites, which if not carefully checked, can be used by hackers to redirect users to malicious websites. The safe practice is to whitelist the values ​​allowed to be redirected within the application

9. Perform checks of data type (data-type, content-type), data domain (data range), data size (data length, data volume) on the server side safely

• This helps to ensure that the input data is strictly controlled on the server side to avoid vulnerabilities related to: Unrestricted file upload, dos, Cross-site Scripting …

10. Always do data validate using a “white list” when possible, avoiding the use of “black lists”.

• Example for data validation with avtar upload function: Instead of blocking unauthorized extensions like (.php, .php3, .svg ..), we do a “white list” of allowed extensions. upload on the server (png, jpg). The guarantee is both safe and saves effort when programming

11. If any potentially dangerous characters are allowed in the application make sure that you implement well safeguards like encrypting the output, securing APIs, and calculating usage. that data in the entire application.

• Examples of common dangerous characters include: <> “‘% () & + ‘”

12. If your data validation can’t handle the following inputs, they should be checked separately.

• Check for empty bytes (% 00): Prevent file upload errors, LFI (Local file inclusion)
• Check for newline characters (% 0d,% 0a, r, n): Prevent code injection errors, LFI, RFI (remote file inclusion)
• Check the characters ../ or .. In case of UTF-8 encoding, check the characters:% c0% ae% c0% ae /: LFI, RFI, Path traversal protection

Output Encoding

This requirement is related to the processing of the output data before the data is displayed on the website. This helps to ensure that the data displayed will not be malformed or vulnerable to client-side vulnerabilities

1. All output data should be encoded in a safe, reliable system.

• The trusted system can be a server that we manage, and a third-party server that is reliable and secure enough.

2. Use standard encodes that have been tested for safety.

• Using built-in standards has a number of benefits: The algorithm has been tested to be safe, has no implementations from scratch, has specific documentation, is easy to maintain, and can be supported by addition. copper

3. Perform output data encode against data from untrusted sources to be displayed on the user side

• This encoding is to protect against Cross-site Scripting (XSS) vulnerability. We can use HTML entity encoding to perform data encoding

4. Encode all data unless you know it is from a trustworthy source.

• This encoding is to protect against Cross-site Scripting (XSS) vulnerability. Trusted data sources are either purified processed ( HTMl purifier can be used) or from other trusted sources (facebook, google, github …)

5. Contextual cleaning all output of untrusted data for queries for SQL, XML and LDAP

• Discard the display data for SQL, XML, and LDAP queries. This helps to combat vulnerabilities related to SQL Injection, XML injection

6. Clean all output of unreliable data related to the operating system command

• We need to clean and remove data related to operating system commands to avoid errors related to command injection, code injection.

Some common flaws with Input validation and Output Encoding

Input Validation

If we do not handle the data well in this section, then we may face the following security vulnerabilities:

• SQL Injection
• OS Command Injection
• Code injection
• LDAP Injection
• Unrestricted file upload
• Buffer overflow
• …

Output Encoding

• Cross-site Scripting (Reflected XSS, Stored XSS, DOM XSS)

See more vulnerabilities at: OWASP Top Ten

summary

These are the two most important content in safety programming requirements, if handled well these 2 parts, websites will basically become safe and avoid serious vulnerabilities as well as avoid The vulnerability is detected by automatic scanning tools.

See you in part 2!