Ajax Security Guide: Use a good architecture and a safer API to defend against attacks

You should carefully consider the architecture, server access control, status management, and strict verification when using Ajax. We have discussed the architecture. Can you talk about server access control? And how does it help Ajax security?

Andrew van der Stock said: access control is composed of the following components:

• AuthC-who are you?
• Authorization (authZ)-Do you have sufficient permissions to do something?
• Review-security protection for all login accesses to promptly determine what operations will be performed later

The strength of authentication is directly related to factors such as the initial identity and credential type (password, Token, etc. Obviously, if the transaction processing level is higher or the risk of being attacked is higher, the verification level is stronger. Strong verification requires the server-side infrastructure, such as the Access Control Server or the PKI of the smart card.

Authorization is the key. The authorization model of many applications has poor performance and lacks any authorization verification, so that the calling program is allowed to perform those operations with special privileges. If an Ajax application uses client-side authorization, it can prevent attacks to a certain extent, especially when there is no server-side control. Attackers can only change or delete the authorization code and security-related tokens in the disk operation Supervisor (DOM), such as an admin tag.

For Ajax applications, the only security method is to use the server-side authC/authZ for verification and review. If there are two paths: Ajax path and common Web application path, the server-side authentication and review method is used, that is, no path is prioritized, in addition, the security is maintained on the server side rather than separately in these two regions.

What do developers need to know about status management and secure state storage of clients?

Van der Stock said: clients do not have the concept of security status. Each time you receive data from the server, you must verify it again. Developers should not transmit sensitive data to clients, such as authorization tokens, database passwords, or access levels, unless the purpose is to display such information. Returning such sensitive data is even worse, because if the verification fails, the returned data will never be executed.

Finally, sending all data becomes more and more common.

What content does strong verification consist?

Van der Stock said: most users will not intentionally leave you alone, but some will. Strong verification includes:

1. For a string: Maximum length and filtering of Allowed characters.
2. For integer numbers: verification range and symbol. Generally, the default value is "unsigned int" instead of "int ".
3. For arrays, such as drop-down lists and radio groups, use a simple value ("1"... "2"... "3") as the selection item, instead of the data itself. A complete example of this situation includes a drop-down list menu containing a credit card number. Do not use a credit card number as the return value. This will cause direct tampering of the number. Instead, use a simple index value (1, 2, 3, etc.) or a part of the account number as the display option.
4. For check boxes and boolean values: Only the true or false option is required.
5. Create new composite types that can be verified, such as Zip code, because of the built-in syntax rules of the regex class.

Negative verification is similar to the virus definition. It is very difficult to maintain synchronization with new attack methods. In the past 20 years or so, black lists have been used to protect information resources. Developers say "no" to the blacklist method, which is crucial.

Filtering is the only possible security verification method. Using a blacklist (negative verification) for regular checks may lead to some malicious input. Therefore, it is much better to use a test and block data.

Can the above-mentioned steps lead Ajax developers to hackers?

Van der Stock said: by doing these basic jobs-data verification, good architecture, safer APIs (there is no reason to intrude into SQL) and so on, your programs are well protected. Malicious developers are all opportunistic. If it takes 20 times more time to develop a simple attack program on your application than on other programs, therefore, attackers will certainly target other applications. I can say that no application is "secure ". This is why it is so difficult to prevent attackers-we must prevent any attacks, and we have no budget or time to write test code for each vulnerability so far, including known potential vulnerabilities or vulnerabilities that have not yet been discovered.

Many developers are not aware of the need to learn this knowledge. Those who participate in the OWASP local chapter writing are already the conversion of our career, and they may know more about it than I do. On the contrary, I would like to discuss with business personnel-architects and engineers who create new software. They are an important and enlightening force, and they are also the conversion of our career.

Security researchers, for example, I have done more basic research than those who are hackers. However, hackers are highly compensated for finding vulnerabilities in widely used software. They use the same technology to identify and exploit these vulnerabilities. In some cases, they also create their own program zone-SAMY worm is an example.

I hope more Ajax vulnerabilities and usage problems can be revealed, and I also hope that researchers can find more "new" vulnerabilities to be protected. These vulnerabilities do not exist, but we have not found and described them. We hope that we can find these vulnerabilities before those zero-hour attackers. Our research and developers can, or, more likely, fail, implement necessary control over a secure application, with a time delay between the two.

Andrew van der Stock is a leading researcher for Web applications in Australia. He is the arbitration of webappsec and once helped organize the OWASP chapter in the Melbourne region. Van der Stock is leading the compilation of OWASP guide version 3.0, which includes a new chapter on Ajax to Build Secure Web applications.

(