Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security

Web 2.0 Threats and Risks for Financial Services 56

Posted by CmdrTaco from the where-is-my-foil-hat dept.
An anonymous reader writes "Companies are tuning into Web 2.0 but are simultaneously exposing their systems to next generation threats such as Cross site Scripting, Cross Site Request Forgery and Application interconnection issues due to SOA. With regard to security, two dimensions are very critical for financial systems — Identity and Data privacy. Adopting the Web 2.0 framework may involve risks and threats against these two dimensions along with other security concerns. Ajax, Flash (RIA) and Web Services deployment is critical for Web 2.0 applications. Financial services are putting these technologies in place; most without adequate threat assessment exercises."
This discussion has been archived. No new comments can be posted.

Web 2.0 Threats and Risks for Financial Services More

Web 2.0 Threats and Risks for Financial Services

Comments Filter:

  • honestly... (Score:4, Insightful)

    by cosmocain ( 1060326 ) on Monday April 30, 2007 @09:30AM (#18927419)
    ...i don't need some flashy looking online-banking. i just want to transfer money from account a to account b, wonder, where my money has gone, etc. sometimes this little sentence just makes sense:

    keep it simple. for such ordinary tasks there does not have to be great interaction schemes or whatever comes to your mind. it just has to freaking work. and - it's even more secure the simple way? well, then don't tamper with it.

    • Re: (Score:3, Insightful)

      by SatanicPuppy ( 611928 ) *
      With complexity comes insecurity. Nothing makes me happier than an old atm with a limited feature set...You know it's not running windows in the background, you know it doesn't have code interpretation vulnerabilities...It's simple, clean, and elegant.

      Likewise the web presence. Whenever I see data change without a page load it creeps me out. It may be sexy looking, but for every piece of flashy 2.0 Ajax, there is a cost in terms of security.

      Sad to say though, there are people out there who are so conditione

      • Nothing makes me happier than an old atm with a limited feature set...You know it's not running windows in the background

        Sadly, my bank's ATM comes from Diebold, the famous company that we all know, and yes, there's no points for guessing that it runs on windows. I've seen it crash atleast a dozen times with BSODs and funny looking dialogs. I am farely sure that these machines can be reverse engineered, and I prefer using their web interface, which from the headers run on iplanet/solaris. Still I guess I co

      • Re: (Score:3, Informative)

        by mobby_6kl ( 668092 )
        > Nothing makes me happier than an old atm with a limited feature set...You know it's not running windows in the background, you know it doesn't have code interpretation vulnerabilities...It's simple, clean, and elegant.

        Depending on your exact meaning of "old", you might be very, very wrong. Many ATMs do, in fact, run Windows [google.com].
        • Oh I know they do...I saw a photo of one where it had bluescreened, then rebooted to a windows desktop. Some joker had started Windows Media Player, and had left it playing whatever track was included with the OS.

          In my mind, that's just obscene. When I talk about old, I mean super simple code, plain text on a black background, push this for your money, the end. Very simple. Practically unhackable. But build it on Windows, even tossing aside all the known problems with Windows, is HUGELY stupid. You're addin

    • Re: (Score:3, Insightful)

      by goombah99 ( 560566 )
      You'd think some bank could turn this into a marketing ploy. put up a banner saying "please excuse the sluggishness and old fashion style of our web site, unlike our comeptitors we use a transactional accounting system and everything you see on your screen is generated right on our servers. It's safer even if it isn't sexy. But you don't really want your bank to be sexy do you?".

      Now could someone please explain to me what cross site scripting is and why it is so hard to stamp it out.
      • A simple example of x-site scripting would be where a black-hat cunningly crafts a URL that points to a location on the bank's site. A user of the bank visits this location, and an interesting piece of JavaScript that's been injected into the URL causes the user's details (cookies, login details etc.) to be sent to another site, so the cracker can get them.
        • how? if the URL is going to the bank then my browser is "on" the bank's site. How is their latent access to the cookies, and form fields, being retained by the intial site.
          • That was a very simple, very quick example. The Wikipedia article [wikipedia.org] explains it in more detail, but essentially it's possible to create a phishing email which will be very convincing (it's pointing to the bank's own site after all).

            For example, if an attacker hosts a malicious website, which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system

            1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive information, such as billing information.
            2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
            3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, making it look as if it came from Bob (ie. the email is spoofed).
            4. Alice visits the URL provided by Mallory while logged into Bob's website.
            5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server. The script steals sensitive information (authentication credentials, billing info, etc) and sends this to Mallory's web server without Alice's knowledge.

      • Now could someone please explain to me what cross site scripting is and why it is so hard to stamp it out.

        One of the limits on active content (mostly Javascript, but it also applies to some others) is, that a script can only access pages originating from the same server. So a script from server A can change a picture or hide parts of a page which is also from server A, but it is not allowed to do that to stuff comming from server B.

        A cross site scripting vulnerability now enables an attacker to do exactly

  • The real problem (Score:5, Insightful)

    by CastrTroy ( 595695 ) on Monday April 30, 2007 @09:33AM (#18927465)
    The real problem is outlined right in the blurb. That problem is: "without adequate threat assessment exercises". I don't think any of these technologies are inherently any worse than any other method, but the problem is that they don't understand the technologies well enough, and aren't testing for vulnerabilities. It's just like with PHP. Sure you can code your pages with really insecure SQL injection technologies, but there's solutions like prepared statements that make it a non-issue. What I want to know is, why are all these financial institutions jumping on the Web 2.0 bandwagon before they fully understand what they are doing? From my point of view, web 1.0 is good enough, and I don't see why everyone wants to switch so fast.

    • Re: (Score:2, Interesting)

      by Hal_Porter ( 817932 )
      There's an argument that you should do some kind of benefit analysis before you adopt technology I think. Each new thing you add increases the attack surface of the application, so there's no point doing things for purely aesthetic or coolness reasons. Plus most Web 2.0 applications seem to cope very badly with slow or unreliable network connections, and that in itself is a good reason to not use them in critical environments like online banking.

      Fuck it, I'm an old fart and I know it. I'm sure next time I c

    • Re:The real problem (Score:5, Insightful)

      by NickFitz ( 5849 ) <slashdot AT nickfitz DOT co DOT uk> on Monday April 30, 2007 @09:58AM (#18927697) Homepage

      The real problem with TFA becomes apparent at the start of the second page:

      RSS feeds exist in Web 2.0 data format.

      That sentence alone confirmed what I'd been beginning to suspect by the end of the first paragraph: TFA is a mishmash of ill-informed technobabble penned for the purpose of allowing underqualified CTOs to give the impression that they are fully buzzword-compliant.

      • Re: (Score:2)

        by Trails ( 629752 )
        More than that. It's written by the "Director and Founder" of Net Square, "a technology-based security services organization", responsible for such wonderful innovations as "httprint, a web server fingerprinting tool." which looks at response headers and figures out what webserver it is, and "datapipe_http - Raw/HTTP TCP Tunneling", "software based on datapipe port redirector originally written by Todd Vierling in 1995, , opens up a connection with the HTTP proxy server, and uses the CONNECT server:port HT

    • Re:The real problem (Score:4, Informative)

      by dkf ( 304284 ) <donal.k.fellows@manchester.ac.uk> on Monday April 30, 2007 @10:06AM (#18927789) Homepage
      All this "Web 2.0" stuff adds one important attack vector, and that is scripts downloaded from a malicious website that manipulates the user's experience of the real site (e.g. to make extra transfers and yet hide the details of those from your view of the log). The proper solution to this is to only allow scripted control of a site (other than from scripts downloaded from the same site) if the controlled site specifically declares that it is OK for scripts from the other site to do so, a policy which would need to be enforced by everyone's browsers. (Yeah, I know. Good luck with getting IE to adopt a sensible default-deny policy on anything.) Of course, this measure completely stuffs most mashups, but is that such a bad thing? :-)
      • scripts, i believe, dont have access to pages from another domain, so that's not necessary. any web developer worth his weight should not have any sql-injection or XSS vulnerabilities, lest he wish to be stoned, and that only really leaves XSRF, which is much more difficult.

        the only way to really prevent XSRF, that i can see, is having browsers disallow inter-domain POST requests, and making sure all important transactions must be initiated via a POST and not GET request.

    • I've said it before, I'll say it again: we went through the same thing with Windows 95+ and Outlook.

      Masses: "Ooooo look at the shiny features!"
      tiny voice in the distance: "But it's a security nightmare!"
      Masses (louder): "Ooooo look at the shiny features!"

      I don't think any of these technologies are inherently any worse than any other method, but the problem is that they don't understand the technologies well enough, and aren't testing for vulnerabilities.

      Unfortunately They are only part of the probl

  • I think it's foolish to use your usual account and browser for online banking. Just create a separate account, keep the browser clean, don't browse around with that account, and set up good security. That's good for many reasons, not just XSS.
    • that will only help if it's the client's browser that's vulnerable, not the site itself. it wont help with XSS (since, as i just now learned, XSS [wikipedia.org] is just another word for javascript-injection. it's a vulnerability in the server, not the client.)
      • that will only help if it's the client's browser that's vulnerable

        Yes, that's the case you need to be concerned about.

        not the site itself.

        How would the banking sites be vulnerable? They don't allow any kind of user content to be uploaded.

        • Yes, that's the case you need to be concerned about.
          i disagree. i'm fairly confident my browser is secure, and if it isnt and there's an exploit in the wild, i'll probably hear about it in less than a day and there's a good chance a patch will be released by then.

          what i'm not confident about is the competency of the developers that put together the site i'm browsing.
          • what i'm not confident about is the competency of the developers that put together the site i'm browsing.

            It doesn't matter how competent/incompetent the banking developers may be, banking sites just don't have uploadable content.

            Therefore, the XSS attacks you have to worry about (and the only ones you can control anyway) are the ones that use your browser. Those are real and often go undetected for a while before a patch becomes available.

            • banking sites just don't have uploadable content

              pretty much every web-app has uploadable content. any time you fill out a form you're uploading content. every just by modifying the GET params, you could be uploading content that will display on the web page.

              the XSS attacks you have to worry about... are the ones that use your browser

              but that's not XSS [wikipedia.org], that's just a browser vulnerability. they do exist but i cant think of any cases i've heard of in the past that have had a chance at affecting me. XSS, o

              • pretty much every web-app has uploadable content. any time you fill out a form you're uploading content. every just by modifying the GET params, you could be uploading content that will display on the web page.

                Yup, but banking apps only show you what you have uploaded.

                but that's not XSS, that's just a browser vulnerability.

                Well, if a bug in your browser permits third party to be uploaded onto your bank's site (something fairly harmless in itself), then you may have a dangerous XSS. Using a separate account
  • "Many Web entrepreneurs and established software providers are hoping that AJAX can reinvigorate the PC software business by marrying the graphical user interface of desktop computers with the benefits of the Web."
    http://news.com.com/AJAX+gives+software+a+fresh+lo ok/2100-1007_3-5886709.html [com.com]

    This is a little over two years ago, on the subject of Ajax...and Web 2.0/ other buzzwords/works seem to be plugged more on technological forums/media...Who wouldn't want to be hip..Especially when your information's rep
  • Hmmm... my bank's website is still quite web 1.0, and I don't have any problem with that. I don't really see where the '2.0' technologies would improve my online banking experience enough to outweigh the potential security holes. I foresee my bank sticking with 1.0.

    Why is this even being considered?

  • please buy my security solution .. (Score:4, Insightful)

    by rs232 ( 849320 ) on Monday April 30, 2007 @09:58AM (#18927693)
    Shouldn't security be built into these Web 2.0 application from the ground up and not added on as an afterthought.

    • Re:please buy my security solution .. (Score:5, Insightful)

      by Opportunist ( 166417 ) on Monday April 30, 2007 @10:13AM (#18927865)
      Has it ever been that way?

      I was there when a certain bank that better remains anonymous (not because of being innocent, but because they got more & better lawyers than me) jumped the train for online business. All the managers saw how much work could be put onto the customers and how much we can save by not having people come in and actually talk to the teller or drop transfer orders in our boxes. They'd do all themselves! And we can charge them for that! Good God, we need that! No matter the cost! Security? Aw heck, ignore that, who'd dare to attack a bank here (Seriously, that was actually the attitude towards it)? And even, what could go wrong? We got https, we got security certificates, our servers are kept tight by the best people money can buy...

      The average annual damage for actual physical bank robberies is a tiny fraction by now of what online frauds cause. Especially since you get about 90-95% of the guys that come with a gun to your bank, while 90-95% of those coming online slip past you.

      And now everyone's all over security and everyone wants it secure damn right now or else.... But you can't secure something that is inherently insecure. It was designed insecurely, it was created insecurely, it's run insecurely. Yes, the key attack point is the customer, not the bank, but all in all, the damage rests on the banks. Either they pay the damage, or they don't and word gets out, and everyone will stop using online banking. THAT damage, though, would be even higher!

      So take my word for it, nobody will give a rat's rear about security until it's too late. Why should it be different this time?
  • New technologies may present unseen risks. Use with caution.
  • Most programs on telly that mention Web 2.0 think it means "Social Networking". I think that's because the main sites that jumped on the AJAX bandwaggon were the social ones. Security wise, I would think that the more you shift the application to the browser the more you make it open to hacking. Talk about public APIs.

  • CSRF and XSS FAQ's (Score:4, Informative)

    by mrkitty ( 584915 ) on Monday April 30, 2007 @10:01AM (#18927729) Homepage

    The Cross Site Request Forgery FAQ [cgisecurity.com]
    The Cross Site Scripting FAQ [cgisecurity.com]

  • two dimensions are very critical for financial systems

    Urgently, pivotally critical, even.

  • First, I don't know wtf web 2.0 is. Is this something people just made up- or am I not cool enough to know what that means for present day 1 mbit connections. Second, banks aren't using ajax and activex. SSL and certificates, and all the rest is low footprint. Banks are more apt to run into Duke Nukem Forever before web 2.0. This article is pulled out of somebodys ass. I've worked all kinds of banks security and that BS just doesn't fly.

    • Re: (Score:2)

      by Intron ( 870560 )
      web 2.0 doesn't refer to a particular technology. It just means using the web for two-way applications, interaction and sharing instead of one-way presenting static pages. Web as application platform instead of billboard.

      • Re: (Score:2)

        by Knara ( 9377 )
        Er, so web 2.0 started in like, 1995 when you could submit forms?
  • That's what I love about computing. A problem that has been around for years and years becomes a new dangerous threat simply because the developers of new technology didnt know about it before.
  • The Ajax stuff seems best suited to intranet and perhaps B-to-B. Public stuff should probably not use Ajax, especially if it involves money transfer. If you expose your site to a million potential hackers you are at a much greater risk than exposing it to one or two. Or at least don't use Ajax for final verification pages. Maybe use it for proposed transactions.
  • When writing Web 2.0, don't trust anything from the browser because it's not secure and it will be modified by tards and script kiddies.

    The rest is to fill 4 pages so there's somewhere for the adverts.
  • "exposing their systems to next generation threats such as Cross site Scripting, Cross Site Request Forgery"

    New? New how? All this scaremongering is making me feel like partying like its 1999 (obscure millenium bug reference)...again.

    "Web 2.0" (I really can't stand the term), IMHO is largly considered to be the "next generation" sites using AJAX. AJAX is nothing new, its Javascript, XML and DHTML. The principal is EXACTLY the same as a webservice request (its just from a Javascript client).

    So:
    Write secure w
  • I'm going to become rich and famous after I invent this ACME buzzword-detection-device. No seriously, I think the biggest Web 2.0 threat for 'financial services' might be the paychecks from the fried-air department.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close