In J2ME, Which Obfuscation level will be efficient for running Application in Mobile.
Are you specifically talking about the obfuscation level available in NetBeans? Proguard, the obfuscator used doesn't have anything called a level, You could see the various parameters that each level passes to the underlying proguard while you move the slider.
You could learn more about proguard here
http://proguard.sourceforge.net/manual/usage.html
Related
So primarily I try the simple architecture in which I make a common interface's repo and then pull it on every plugin and then implement that, then call the main app for adding the plugin and run it dynamically while running.
interface PluginI {
val core: CoreApplication // Means of communication with core app, this obj is sent by core app by constructor
fun version(): Double
suspend fun load(pluginConfiguration: PluginConfiguration)
suspend fun run()
}
But how should the plugin be restricted to some area, such as protection from potentially destroying, hijacking or crashing the main app? Especially it should be restricted from using anything from jvm's static classes such as System, an example of some hijacking app is that it could do a System.getRuntime().exec() which could be execute exploits in shell.
Sandboxing isn't the solution, or is it? Because it just breaks the connection between the main app and plugin.
I am searching for a solution which gives only a shared object from which main app communicates with plugin and send some info it wants such as date/time or whatever that can't hurt runtime.
Creating sandboxed environment in java is pretty much impossible, with java 9+ you could use modules to make this a bit easier... especially if you want to allow some kind of reflections.
But allowing reflections otherwise is really hard and risky, and everything you do should definitely work as a whitelist, blacklists just "don't work" (aka, I don't believe anyone will be able to find all the things to include and remember to keep it updated when updating any of your dependencies).
Java have a build-in system for such stuff and its called SecurityManager, your application should setup own SecurityManager and use it to filter every method call and only allow for invocation of method from the same plugin as it was called from and block any kind of reflections, block changing security manager and block any manual class loading.
Additionally java 9 modules can be used to simplify this setup, as modules can even block calls between modules while not restricting reflections on classes from the same module. But it can't replace security manager fully.
Also just remember that no matter what you do, someone can still cause your application to become unstable, especially if you will allow any kind of I/O or own threading. But plugin can still allocate huge amount of memory or just run infinite loop - or actually just both at the same time ;)
And there is no way in java to either force thread to be stopped or limit amount of allocated memory from some code.
The only partial solution for this I could see would be to use java agent to instrument code of each plugin and add calls checking if thread was interrupted inside any code that could run for too long.
Same would be possible with allocations.
But then you also need to be 100% sure that none of the whitelisted methods can loop or allocate too much at once.
Basically: don't.
It's only good solution (without the agent) if you can trust plugin a bit but you just want to set some rules to avoid bad practices. It will not stop someone who wants to break something, but will stop typical programmer from creating non-clean code.
If you need to run untrusted code... either run it in actual sandbox on OS level, like look at sphere engine and only communicate with it in some safe way.
Or use some other language that offers you to do the same as stated above but much easier, like Lua. http://lua-users.org/wiki/SandBoxes
You can then run such language from java using script engine https://github.com/luaj/luaj
But even then its hard to be 100% sure it will work right and that there are no holes someone will find and use, as it does not take much if all that an attacker will need is to stress cpu/memory enough to disrupt main application.
Sorry if this is not a place to ask these questions. But I just want to know if...
Can JHipster go large scale applications?
Is it possible to minimize the generation of codes especially with the UI part?
Can I extend some RestController class that has been generated to. (Like a custom model class where in I get base64 string to write in a file)
Sorry again for asking, its just that I'm building a startup business and I want to know if these are all possible. I can't help but to get over excited on JHipster and I'm literally crossing my fingers now!
Thanks guys!
Three questions in one, in fact!
It depends of what you call "large scale". We have users with several hundreds of tables, so that's what I would qualify as "large". Other people use a "micro service" approach, with several JHipster apps working together, and that's what I'd recommend. Our Gatling tests (as well as feedback from users) also show we are able to sustain a large amount of HTTP requests, compared to "competing" stacks such as JBoss or Play! (but both of them don't have default settings oriented towards production, like our "prod" profile - for example they don't have a 2nd level cache enabled by default - so that's normal we are much more performant out-of-the-box)
If you don't like the UI part you can remove it, but in that case I would recommend not using JHipster -> this is the whole idea, otherwise just use a bona fide Spring Boot, or DropWizard
It's just a generator, so yes you can extend or modify anything that was generated
yes you can, i have used it for one educational board who have 20housand+ js file, and also used it for 3 ministry
I'm looking for a way to output traces to a log file in my code, which runs on linux.
I don't want to include the printing information in the binary, in every place I deploy it.
It windows, I simply used WPP to trace without putting the actual traces strings in my binary.
How can this by achieved in Linux?
I'm not very familiar with Linux tools in this area, so maybe there is a better system. However, since nobody else has made any good suggestions, I'll make a suggestion. (Probably not a very good suggestion, but the best I can think of right now.)
In theory, you could continue to use wpp. Wpp is simply a template system. It scans the configuration and input files to create data structures. Then it runs a template, fills in the data values it got from the scan, producing the tmh files. You could create a new set of templates that would use Linux apis instead of Windows apis, and would record the message strings in a way that works with some other log decoder system.
I noticed this question only now and would like to add my two cents to the story just for a case. Personally, I truly appreciate Windows WPP Tracing and consider it probably the best engineering solution for practical development troubleshooting among similar tools.
It happened I extended WPP use to Unix-like platforms twice. We wanted to use strong sides of WPP concept in general and yet use it in a multi-platform pieces of code. This was not a porting but rather a wrapper to specific WPP use we configured on Windows. One time we had a web service to perform actual WPP pre-processing on Windows; it may sound a bit insane but it worked fine and effective within the local network. A wrapper script that was executed before each compilation sent a web request, got a processed file and post-processed the generated include file to make it suitable for Unix-like platforms. The second time we implemented a simplified WPP pre-processor of our own (we found yet additional use for it - we could generate the tracing statements differently for production and unit testing, for example). This was a harsh solution: you anyway need to use some physical tracing framework behind the wrapper on non-Windows platform (well, the first time we apparently implemented our own lower level).
I do not think the Linux world has a framework comparable to WPP. Once I even thought it could be a great idea to make an open source porting project for WPP. I am not sure it would be much requested though. I said it is a great engineering solution. But who wants to do dirty engineering work? Open source community prefer abstract object-oriented and generic solutions, streaming and less necessity in corresponding tools (WPP requires special management tools and OS support).Ease of code writing is the today's choice.
There could be Microsoft fault (or unwillingness) in the lack of WPP popularity too. They kept it as an internal framework that came out just by a case with Windows DDK because they have to offer some logging/tracing solution for driver developers. Nobody even noticed much that WPP is well suitable for the user-space code too. And WPP pre-processor for C#, for example, has never been exposed to public at all.
Nevertheless, I still think that WPP porting to Unix/Linux work can be a challenging, interesting and maybe even useful attempt. If someone decides to lead it. :)
I have this doubt since a while and today I'm not so strong a position, despite having taken one.
Whenever I develop or participate in the development of an application (WEB), typically treat security finger-and-nail, that is, we treat all processes related to security, sessions until encryption of passwords, etc.
I remember hearing someone say that it is always better to use a Framework (Spring, Apache Shiro, etc).
What is your suggestion?
Yes it is always better to use a framework rather then re-inventing the whole wheel again. I personally prefer Apache Shiro and have made customizations to suite my needs by extending classes provided.
REad here http://shiro.apache.org/
Some points to meke up your mids are:
Custom code equals custom vulnerabilities: With web applications you typically generate most of the application code yourself (even when using common frameworks and plugins). That means most vulnerabilities will be unique to your application. It also means that unless you are constantly evaluating your own application, there’s no one to tell you when a vulnerability is discovered in the first place.
You are the vendor: When a vulnerability appears, you won’t have an outside vendor providing a patch (you will, of course, have to install patches for whatever infrastructure components, frameworks, and scripting environments you use). If you provide external services to customers, you may need to meet any service level agreements you provide and must be prepared to be viewed by them just as you view your own software vendors, even if software isn’t your business. You have to patch your own vulnerabilities, deal with your own customer relations, and provide everything you expect from those who provide you with software and services.
Reliance on frameworks/platforms: We rarely build our web applications from the ground up in shiny new C code. We use a mixture of different frameworks, development tools, platforms, and off the shelf components to piece them together. We are challenged to secure and deploy these pieces as well as the custom code we build with and on top of them. In many cases we create security issues through unintended uses of these components or interactions between the multiple layers due to the complexity of the underlying code. When we can use for all other parts why not use for security and just keep and eye if any vurneability is found in that framework and respond by updating as community can update faster and better than by oneself.
We have developed a small web application for a client. We decided on the Dojo framework to develop the app (requirements included were full i18n and a11y). Originally, the web app we developed was to be a "prototype", but we made the prototype production quality anyway, just in case. It turns out that the app we developed (or a variant of it) is going to production (many months hence), but it's so awesome that the enterprise architecture group is a little afraid.
508c compliant is a concern, as is security for this group. I now need to justify the use of Dojo to this architecture group, explicitly making the case that Dojo does not pose a security risk and that Dojo will not hurt accessibility (and that Dojo is there to help meet core requirements).
Note: the web app currently requires JavaScript to be turned on and a stylesheet to work. We use a relatively minor subset of Dojo: of course, dojo core, and dijit.form.Form, ValidationTextBox and a few others. We do use dojox.grid.DataGrid (but no drag N drop or editable cells, which are not fully a11y).
I have done some research of my own, of course, but I any information or advice you have would be most helpful.
Regards,
LES2
I'm not sure how to answer this question except to point out that you'd be in good company using Dojo. Several large corporations, deeply concerned about security issues have contributed to the toolkit and use it in their own products. Audits have been done on the toolkit, including one recently which did expose a problem which was quickly patched -- in fact, the CDN feature of Dojo, if you use it, means you can pick up patches like this automatically. Other than that, I'm not sure what proof to offer. A toolkit is secure until someone finds a security hole! Also, there are plenty of things you can do with Dojo, or the underlying HTML/JS technology, which are not secure. You need to follow best practices. One example is with JSON. There are a couple of methods to handle JSON. The base one is fast, works on older browsers, but is known not to be secure. It is meant to be used only with trusted data sources, and typically with the same domain policy, that's what you'll be doing. There are alternatives in dojox.secure which you might want to look at, depending on what you're doing, you may be able to provide an extra level of security to your application.
For performance, you can look at the various benchmarks like taskspeed, which focus largely on the dojo.query DOM traversal functionality common to most toolkits. Of course, YMMV depending on your usage of Dojo, but there's healthy competition between the toolkits and continuous improvement with each release.
For accessibility, all Dijit widgets were reviewed and considered to be 508c compliant. There is more precise documentation on Dojo/Dijit a11y requirements. Not all dojox widgets pass this requirement.
HTH