Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am creating a SaaS that will be delivered through a Vertical Information Portal (VIP).

In my research I have found that by developing a custom lean web browser and installing it on the clients platform, I can better restrict access to the portal on the web by only allowing this custom browser to access it.

I realize there is a threat of duplicating the the client browser. but I feel it is better option instead of any browser being able to access the portal to receive the payed services, and much easier to flag for piracy.

However, in regards to security of a custom browser, I have not been able to find any useful information. I would elaborate on this point, but unless I am missing something (which is probably the case), I have nothing to go on.

Can you point me in the right direction to make a thorough threat assessment on a custom browser build for a VIP delivered SaaS?

EDIT

By looking at the possibilities of a customized connection from server to client, I am not trying to re-invent the wheel, but looking at innovative options to make improvements to the wheel.

I do not make the assumption that any system is totally secure, and I fully believe the practice of IT Security is a constant work in progress that must be improved on (hence, the purpose of this question).

share|improve this question
add comment

2 Answers 2

up vote 3 down vote accepted

It sounds to me like you want your Web based SaaS application to be accessed only by browser/client/hosts that have some system integrity properties that are usually lacking in a typical web client host -- e.g. absence of malware, resistance to malware. If that is so, then you should consider developing a client that is a hardened dedicated browser appliance: a) delivered to users as a liveCD image to be booted on typical PC HW from RO media; b) built using SE Linux and bootstrap to restrict the executable application software to consist of a web browser; c) local packet filter configured to permit communication only with the host(s) of the server side of the application; d) browser configured to trust only the server certificate of the server side of your application; e) several other supporting characteristics, but that's the gist.

An worked example of hardened dedicated browser appliance is available at: https://github.com/trustthevote/BrowserAppliance In addition, you will probably want to build into the client image a key pair and PK certificate that the server requires as a pre-req for service. As you point out, it is certainly possible for the cert and key pair to be extracted and used by a different client host; but it is a strong measure to prevent casual or accidental use of "normal" client hosts such that the server would interact with these risky clients. If your application uses strong user authentication, then you de-scope your risk further by limiting the pool of people who would benefit from something as weird as cracking keys out of a perfectly usable hardened dedicated browser appliance, in order to rig up their existing PC as a client, without having to boot from RO media as a pre-req for using your application.

Hope this helps! John Sebes http://osdv.org

share|improve this answer
1  
This is exactly the type of innovative thinking for creating a customized client/server portal via the open web I am looking for. Also, thank you for taking the time to lay out key factors/characteristics to consider for such a build, and providing a worked example. Great answer!! This does help. Thank you! –  Chad May 22 '12 at 2:36
    
@John Sebes so in this case you are providing a secure client that is resistant to compromise. However, would you agree that if an attacker had one of these clients the same types of security issues found on the OWASP top 10 are still a serious threat and that is not diminished by this security measure. –  Rook May 23 '12 at 9:24
    
@Rook, do you have some insight to add besides the obvious that no system can be totally secure? Possibly a checklist of known threats and possible viable precautionary measures that are currently working to some extent. Your profile relates to Trust No One. Can you shed some light on this in regards to the topic question and share your knowledge on ways to prepare for the eminent attack? –  Chad May 24 '12 at 19:47
    
@Chad New attacks are found on a regular basis. Format string attacks where not exploited until 1999 or so. The first dangling pointer exploits didn't arrive until ~2007, but now they are commonly used to leverage systems protected by ASLR. There is absolutely no security in building an obscure system from scratch, if anything you will be far less secure because you don't have a community of hackers improving the system. Firefox and Chrome are very secure because of the community. –  Rook May 29 '12 at 1:24
    
@Rook, Very insightful and informative. This gives me solid foundation to measure pros/cons for a system of this nature. Thank you for taking the time to share your knowledge. –  Chad May 29 '12 at 13:16
add comment

This is (in)security though obscurity, I don't see how this improves the security of any system. Probably the reason why you can't find any information on this topic is because its not a good idea. I suspect you would also implement your own HTTP protocol, and then forbid clients from sniffing the wire with wireshark/tcpdump. Oah and you will have to forbid the client from opening their own socekts, and access to telnet...

But all that aside, I can still find and leverage xss/csrf/sql injection/whatever using just a web browser... What is keeping the attacker from putting sql statements into an html form or the address bar. So by reimplementing the wheal you are already giving the attacker a perfect tool to compromise your system.

Whats the point?

share|improve this answer
    
You bring up a very good point referring to injection methods used. I believe that any method used has its vulnerabilities. Even though the acceptance of using secrecy as a method of security is not an ideal approach and NIST highly recommends not using it, I believe it has value if used in conjunction with other security methods as a Defense in Depth approach. –  Chad May 21 '12 at 3:32
    
@Chad Its only defense in depth if it can actually prevent an attack. I don't think that rebuilding all of the protocol, the client and server from scratch actually accomplishes anything. I have seen this question before on SO, and it was shot down. –  Rook May 21 '12 at 3:45
    
you bring up some very good points. Can you elaborate a little further for me on your sources? Your question of whats the point, and belief that a client/server from scratch build would not accomplish anything, does not (yet) help me to make a thorough threat assessment. To clarify a little further, I believe that the widely popular adoption of HTML5 and CSS3 did loosen the hold Flash had on rich interactive user interfaces, it creates a huge security threat. But by just making that statement with out going into detail and stating resources to back my opinion, it is just an assumption. –  Chad May 21 '12 at 16:47
    
@Chad i think the burden of proof is on you. I don't see how it prevents any attack. –  Rook May 21 '12 at 16:55
    
Thank you for your input. –  Chad May 21 '12 at 17:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.