Search the Community

I'm rolling out a mass market app developed using smart mobile studio. I have compiled with code packing and obfuscation options. Is the compiled code secure from reverse engineering and simple hacking? Are there any third party html/js security tools you can recommend for strong code protection?

I'm seeking help in making this Delphi code (from http://www.codeface.com.br/?p=1679) work in SmartMobileStudio. function EncryptStr(const S: String; Key: Word): String; var I: Integer; const C1 = 53761; C2 = 32618; begin Result := S; for I := 1 to Length(S) do begin Result := char(byte(S) xor (Key shr 8)); Key := (byte(Result) + Key) * C1 + C2; end; end; function DecryptStr(const S: String; Key: Word): String; var I: Integer; const C1 = 53761; C2 = 32618; begin Result := S; for I := 1 to Length(S) do begin Result := char(byte(S) xor (Key shr 8)); Key := (byte(S) + Key) * C1 + C2; end; end;

Hi I am looking for sample code for signing in via Facebook, Twitter or Google account to authorize app use.

I recently had a look at Scott Helme's site, https://securityheaders.io Scott is involved in information security and his site explains in great detail how to enhance site security by means of http response headers. Quoted : "HTTP Response headers are name-value pairs of strings sent back from a server with the content you requested. They are typically used to transfer technical information like how a browser should cache content, what type of content it is, the software running on the server and much, much more. Increasingly, HTTP Response headers have been used to transmit security policies to the browser. By passing security policies back to the client in this fashion, hosts can ensure a much safer browsing experience for their visitors and also reduce the risk for everyone involved. Let's take a look at some more security based headers. The first step in hardening your HTTP response headers is looking at the additional headers you can utilise to make your site more secure. Outlined below, these headers give the browser more information about how you want it to behave with regards to your site. They can be used to deliver security policies, set configuration options and disable features of the browser you don't want enabled for your site. Once you have setup each header, check it using SecurityHeaders.io." His site features a facility to scan any domain, giving back information on which headers to check. So I scanned a standard SMS project output (Visual Component Projects). The results indicated to add security policies by including the following headers : - Content-Security-Policy - X-Frame-Options - X-XSS-Protection - X-Content-Type-Options The first (Content-Security-Policy) can prevent the browser to load malicious assets by white-listing what is permissible and what is not. The second (X-Frame-Options) can be used to prevent click-jacking by disallowing your website to be framed. The third (X-XSS-Protection) can be used to properly configure the browsers built-in security function (reflective XSS protection) The last (X-Content-Type-Options) reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as for instance an executable. Sounds all pretty good to me. The Content-Security-Policy (CSP) is probably the most important. It also comes with a heap of options and the list of permissable resources can be left wide open or screwed down to zero and everything in between. Experimenting a bit I settled on <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' http://yourdomain; img-src 'self' http://yourdomain;"> The first line is the default for 'nothing is permitted'. This will stop the browser from downloading any script, any font, any image, any css file etc. The following lines override this behavious somewhat. The second line handles scripts. The self parameter means that scripts in the same directory as the index file are permissable. Depending on your project linker options either the js is included inline in the html file or a separate 'main'js' file is created which is referenced from the html file (<script type="text/javascript" src="main.js"></script>) The latter is preferred anyway, using inline JS or CSS is considered unsafe as it provides at least an opening for attackers to inject script into a page. Unfortunately the 'external scriptfile' linker option still leaves a small bit of inline js in the html file : <script type="text/javascript"> /* This prevents the window being moved by touches, to give the impression of a native app */ document.ontouchmove = function(e) { e.preventDefault(); } </script> Would be better to include this in the external file as well. For now in both linker options the keyword 'unsafe-inline' is required The third and fourth line handle css-files and images. Since usually the styling info is in a subdirectory (res/app.css) and the images are in a subdirectory as well, the domain must be specified. There are additional parameters to handle for instance http-requests, permissions for audio and video handling and more. The other 3 response headers are valid for all servers but the syntax is slightly dependant on server-type. For nginx servers I believe the following headers are valid : <meta http-equiv="X-Frame-Options" content="'SAMEORIGIN'"> <meta http-equiv="X-Xss-Protection" content="'1; mode=block' always"> <meta http-equiv="X-Content-Type-Options" content="'nosniff' always"> just include these meta tags in the header section of the default.html file in the Templates sub-directory prior to compile and link.