What's the Appeon encryption mechanism
Posted by Nico Wang on 07 June 2013 11:08 AM
For Appeon encryption mechanism, please refer to the article below：
Appeon’s security is a second level security, it is originally a PowerBuilder application and the client/server developer should take the security issue into consideration during the programming. Appeon also did a lot of work to secure the data transferred on the Web/Mobile, and the customer use Appeon together with other security guard mechanism to ensure the data safe on the Web/Mobile. First of all I will give you a general introduction of how Appeon secures the application and data.
How does Appeon ensure the data secure?
The strong Web/Mobile security section in the whitepaper may be useful for you to understand what tasks Appeon has done to secure the customer’s application.
Strong Web/Mobile security
Appeon supports the leading Web/Mobile security standards and measures to ensure that all data transmissions are safe, secure, and authentic.
Below are the main Customer’s concerns on Appeon’s encryption mechanism just for your reference:
A1 - Cross Site Scripting (XSS) XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
<Appeon>: HTTP requests between Appeon client and Appeon Server are encrypted and validated.
A2 - Injection Flaws Injection flaws, particularly SQL injection, are common in web/mobile applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.
<Appeon>: Appeon encrypts all HTTP requests to avoid attacking. Firstly, Appeon will use gzip to compress the data and then use the confusion technique to encrypt the data. Appeon also supports using SSL certificate on the server to add more secure for the HTTPS requests. If the attacker modifies the HTTP/HTTPS request it will fail the whole request.
A3 - Malicious File Execution Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
<Appeon>: All the JS, XML and HTML running on the client side are encrypted. Before transferring those files to the client side, Appeon Server will generate identifier for each file and encrypt the file. When clients need to run these files, Appeon Web library will validate the identifier with Appeon Server. The encrypted files will be decrypted and run on the client side only there is no problem on validating the identifier. If these files are injected with hostile code, the validation will definitely fail. Therefore these files cannot be decrypted and run on the client side.
A4 - Insecure Direct Object Reference A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
Sensitive data will be handled in a more secure way. Expect encrypting those sensitive data (for example, Key, database records, URL), this information will also be stored on the server side. This information can only be gotten with the correct validating code and the related request will be handled on the server side. Also the validating code is encrypted in multiple ways and it is impossible to get information.
A5 - Cross Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web/mobile application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web/mobile application that it attacks.
<Appeon>: All Appeon client requests will have the identifier that can only be recognized by Appeon. If any third-party program modifies the HTTP request, Appeon Server can easily indentify this.
A6 - Information Leakage and Improper Error Handling Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
<Appeon>: APB can secure the application in a certain level, but we cannot guarantee everything after all the developer himself should take the application secure into the consideration during the programming stage. For example, they need to avoid putting sensitive information in an INI file. No matter what platform or tool, it only offers basic security mechanism to secure the data, the developer should also be responsible for coding secure application which is out of the control of Appeon.
A7 - Broken Authentication and Session Management Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
<Appeon>: Two things will be emphasized in this case. First of all it is very hard to get Appeon’s session information, since the session information is stored in the Appeon HTTP requests which are encrypted. Second even they can get the session information; they cannot do any operation since every request sent to Appeon Server should be consistent with the Appeon recognized format which is encrypted. Besides, the format of each type of requests is different, it is a combination of binary data, and any single bit validating failure will fail the whole request.
A8 - Insecure Cryptographic Storage Web/Mobile applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
<Appeon>: Every HTTP request in Appeon is encrypted and you can also use SSL (HTTPS) to make your application more secure.
A9 - Insecure Communications Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
<Appeon>: It can be prevented by using SSL (HTTPS) which is supported in Appeon.
A10 - Failure to Restrict URL Access Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
<Appeon>: First of all the client/server is supposed to be a well designed application with sufficient authorization. Even they pass the authorization, they cannot pass the validation of Appeon Server since the identifier is applying Appeon unique format.