The term "Appeon" in the following article refers to PowerServer 2020 or earlier. If you are looking for the security measures of PowerServer 2021, please visit this link.

 

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?

 

  1. All data transferred between Appeon client and Appeon Server will be compressed using gzip. If HTTPS is applied, data will be further encrypted according to the encryption algorithm of the SSL certificate on the server.

  2. Both Appeon client and Appeon Server will first of all validate the data, to ensure this is a data or request comes from Appeon Server or Appeon client. Every Appeon sent request or data is labeled with identifier that can only be recognized in Appeon. The identifier is also encrypted.  

  3. All the requests sent from Appeon client side can be transferred in HTTPS, and the information between Appeon client and Appeon Server is transferred in encrypted data stream.

 

Strong Web/Mobile security

 

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.

Appeon supports the leading Web/Mobile security standards and measures to ensure that all data transmissions are safe, secure, and authentic.

  1. First and foremost, Appeon Web/Mobile applications are compatible with all corporate firewalls since Appeon communicates using HTTP over port 80 and only Web/Mobile documents pass through the firewall (e.g. .HTML, .XML, .JS files).

  2. The Appeon client-side utilizes only non-invasive Web technologies that cannot bypass the Web browser security sandbox.

  3. Appeon will generate the hash codes for all the PB codes and additional files that are deployed via the Appeon Developer, thus the web/mobile application won’t be run correctly and request the data from the Appeon Server if the user manually modifies the file on the client machine or the server.

  4. Except for the Appeon ActiveX control that contains signed certificate (this is only for the web application), all files are implemented using only HTML, JavaScript, and XML. Appeon’s built-in multilevel deployment security and application security ensures that unauthorized developers cannot deploy files to the server, and unauthorized users cannot access the system even when it is deployed to many different users over public networks (Internet).

  5. Deployment security can be easily applied to an Appeon Server by simply configuring a setting in the AEM (Appeon Enterprise Manager). This feature helps safeguard the server from unauthorized application deployment.

  6. Most existing PowerBuilder application security measures are automatically replicated in the Appeon Web/Mobile application. This includes features such as specifying privileges for accessing particular menus, windows, functionalities within windows, and even DataWindow data (columns).

  7. Appeon adds a second layer of application-level security on top of the existing PowerBuilder application security. Application level security will authenticate users based on logon credentials (e.g. username/password and IP address) before allowing the user to logon to the application. The user access can be managed using an LDAP server or Appeon’s on built-in system.

  8. Session timeouts can be easily applied to all Appeon Web/Mobile applications by simply configuring a setting in the AEM. This feature helps safeguard the application from unauthorized access when authorized users have stepped away momentarily or forgot to logout from the system.

 

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 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.

<Appeon>: The original PowerBuilder application will be parsed into encrypted JavaScript code so there is no direct object reference on the Web/Mobile.

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.

  

 

  
0
1