Web security

From Xojo Documentation
Jump to: navigation, search

The Security Behind Xojo Web Applications

We take the security of your web application very seriously in the Xojo web application framework. Because web applications are accessible to any number of online users, the security of web applications is paramount.

Most traditional web development languages are interpreted, meaning your web application is a set of files on a server. If someone gains access to that server, they gain access to your source code. Xojo web apps are compiled to binary code so your source code is not stored on the server.

In order for someone to alter your application they would have to be very familiar with x86 assembly code and be willing to spend a very, very long time tracing through that code. This is, at the least, an order of magnitude far more difficult than hacking HTML, JavaScript, CSS, AJAX, and PHP or Java source code.

The Open Web Application Security Project (OWASP) provides information on web application security and recently posted a list of the top 10 web application security issues. While a few of these issues require the developer to be more diligent, most cannot be used to hack into a web application created with Xojo.


Hack Xojo Protection
SQL Injection Attacks US: Provides developers with prepared statement support for database access. This takes the values to be used in a query and sends them separately to the database server so that it can determine if the values are valid or contain SQL.
Cross-Site Scripting Applications created with Web Edition can’t be used for this purpose because all data sent to the browser is automatically escaped. As a result, the user cannot inject HTML into a page. Also, because the developer doesn’t work in HTML or JavaScript, there’s no way for the developer to accidentally create this security breach.
Application Authentication Xojo does not have authentication routines to compromise and session tokens are automatically protected from theft.
Insecure Direct Object References Xojo does not allow direct object references in this manner so it would be impossible for such a security hole to be created.
Cross-Site Request Forgery When the user logs into a web site (such as a banking site) and then leaves by navigating to a page of another site without first logging out, the original site will still see the user is logged in until their session times out. The developer can mitigate this by reducing the timeout from the 60 second default.
Security Misconfiguration This involves the developer making sure they have good passwords for their server, not exposing data that does not need to be exposed, etc. This particular security concern is completely within the control of the developer and is outside the scope of what any development tool can guard against.
Insecure Cryptographic Storage Be sure to use appropriate function in the Crypto module to properly secure your data.
Failure to Restrict URL Access Because Xojo web apps create the HTML page on the fly, there’s no way for a hacker to access any page except the one that is currently in their browser. However, if the developer chooses to support bookmarking, they would need to make sure they authenticate the user before taking the user to the requested page.
Insufficient Transport Layer Protection Web Servers provide SSL support which is the appropriate place to handle this issue.
Unvalidated Redirects and Forwards There is nothing any development tool can do to prevent this. It’s up to the developer to make sure their app doesn't depend on untrusted data when redirecting or forwarding the user to another site. For example, the developer should always use the EncodeURLComponent function to encode any values used in a URL which come from a user or database.


Go here to read a full description of each of these types of hacks.

Personal tools
Namespaces

Variants
Actions
Main
Documentation
Community
Toolbox
Help