Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Simply Irresistible

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Simply Irresistible

    ** This thread discusses the article: Simply Irresistible **
    ** This thread discusses the Content article: Simply Irresistible **
    0

  • #2
    Simply Irresistible

    ** This thread discusses the article: Simply Irresistible **
    Lastly, because widgets support JavaScript, an infection would have the ability to jump from platform to platform. This includes potential jumps to OS/400 and i5/OS, which have traditionally been viewed as immune to virus attacks. Can anyone provide a technical justification for this statement? I think it would have to be something running within the HTTP server job, with some kind of execute any SQL statement that comes back in this box type thing. I don't know, it's a shame these kinds of things can even be asserted about the AS/400. I do not see stateless HTTP access to the AS/400 as worth being dragged down into this filth. We used to talk about a small AS/400 exposed to the internet accessing data via DDM. The same programming stupidity assumed above would not be eliminated, but it couldn't access our data. In any event, I think ISP ranges not from your geographical area, for example, non-ARIN in North America, should be white listed for access. All this crap is coming from overseas and if they were legitimate customers you could white list them, and block out the organized criminals. It's real simple. I do it on my web site. rd

    Comment


    • #3
      Simply Irresistible

      ** This thread discusses the article: Simply Irresistible **
      Ralph: Can anyone provide a technical justification for this statement? No. There is no way a JavaScript function can execute arbitrary code on a System i. Article: It is not necessary to directly attack System i or execute code under i5/OS to compromise the data stored on the system or bring down the network that it serves. This is simply untrue. Code MUST execute on the System i in order to update data on the System i. It may be the database server, or it may be via a remote procedure call, or it may one of a few other methods, but each of those must be explicitly enabled in order for an outside entity to update data. This is one of the reasons I constantly rail against ODBC access to the System i. If you DO have an unfettered ODBC connection, it is conceivable that a rogue Windows application could sniff that connection and access your data. But this requires two things: 1. An infected Windows machine. 2. An open door to your iSeries. Anyway, note that none of the list of security breaches in the article mention a System i. when you read an article like this, be sure to see if there are any concrete examples of threats to the System i. To date I have never found one. Joe

      Comment


      • #4
        Simply Irresistible

        ** This thread discusses the article: Simply Irresistible **
        Thanks, Joe. I didn't think this was valid, but I'm assuming this unnamed FUD is based on some variant of cross site scripting where the bad buy indirectly gets authority to access data on the System i by injecting and executing Javascript into a legitimate system i user's web page. I know that vulnerability existed on a widely used web site management tool but not in the one I use, and that basically it has to do with the quality of security coding on the web server side in parsing input and output through web pages. It's sort of loose enough that a vendor like this can make broad claims even against the System i given for example a PHP program such as above could be running within the web server space. I don't know. I haven't looked into this any deeper because it didn't affect me so far, but unfortunately we just had a vendor slime the System i on one of its greatest strengths, security, with ambiguous claims. It certainly smells like a vendor's FUD. rd

        Comment


        • #5
          Simply Irresistible

          ** This thread discusses the article: Simply Irresistible **
          Ralph, JavaScript can't do ANYTHING directly on the server. JavaScript runs solely on the browser. The only thing it can do is send HTTP requests to the web application server. If your web application is bad enough that a malicious HTTP request can crash your data, then you've got much larger problems than JavaScript. If you design your pages to avoid basic hacks like SQL injection, then JavaScript can't harm you. Period. If, on the other hand, you start running PHP programs from someone you don't know, then you are indeed opening yourself up. But that goes for any software you might think to incorporate into your system! Joe

          Comment


          • #6
            Simply Irresistible

            ** This thread discusses the article: Simply Irresistible **
            I understand. It's indirect, and it's what the injected Javascript into the web page signed on to a System i is doing to the HTTP request (cross site scripting) that is the only thing that I think this vendor could be implying about the System i, but even given the widest latitude, "virus jumping to i5/OS" is without merit. Claims of this sort against the System i, especially to sell something, should be challenged in my opinion. Thanks for setting things straight, Joe. rd

            Comment


            • #7
              Simply Irresistible

              ** This thread discusses the article: Simply Irresistible **
              But once again, JavaScript doesn't affect the host, it affects the client. Cross site scripting can't possibly get at anything on the System i unless you have a larger security hole. Let's be absolutely clear on this: JavaScript cannot affect System i data. If there is a hole, it's because the web application is not properly performing the most basic of security measures, and that hole exists with or without JavaScript. No virus can pass, no JavaScript can attack, no objects can be created, no programs can be run without explicit enabling actions by the System i programmer or the system administrator. Certainly the programmer can open a hole and allow anything to happen, but unlike desktop OS's like Windows, unless such a hole is open there is no way to insert a program into a System i and run it. Now if you really WERE worried about this sort of thing, then you'd need to disable FTP and ODBC and most of your host servers, set up exit points using something like PowerLock. Either that, or completely remove your machine from Internet access. Joe

              Comment


              • #8
                Simply Irresistible

                ** This thread discusses the article: Simply Irresistible **
                ODBC is indeed an open hole, but even with ODBC, only data will be at risk. As I understand the definition of a virus, it is an infection that changes the behavior of programming, and programs. That cannot occur with the use of ODBC. Dave

                Comment


                • #9
                  Simply Irresistible

                  ** This thread discusses the article: Simply Irresistible **
                  Well, sure, you can't run a program with ODBC (except maybe a trigger or an exit point), but "only data will be at risk" is quite the problem, don't you think? Even read-only access opens you up to the same issues that Mr. Jones was talking about. Personally, I think unmanaged ODBC is at least as bad a threat as a virus. Joe

                  Comment


                  • #10
                    Simply Irresistible

                    ** This thread discusses the article: Simply Irresistible **
                    I was not attempting to minimize the danger to data, but rather point out the invulnerability of OS/400 programming. Dave

                    Comment


                    • #11
                      Simply Irresistible

                      ** This thread discusses the article: Simply Irresistible **
                      with an SQL call: call qcmdexc('wrkoutq qezjoblog', '17')

                      Comment


                      • #12
                        Simply Irresistible

                        ** This thread discusses the article: Simply Irresistible **
                        Hmmm. I haven't actually tried that one, Os. As soon as I get a chance I'll wumpus up a Java program that attempts to do that via JDBC. If that works, then I'm going to raise my personal assessment of the ODBC threat level from Orange to Red. Joe

                        Comment

                        Working...
                        X