Java su iPhone, Sun non si arrende

Sun nutre ancora la speranza di poter raggiungere un accordo con Apple per il porting di Java su iPhone. Nel frattempo ha collaborato allo sviluppo di un software capace di convertire i programmi J2ME in applicazioni native per iPhone

Roma – Ad oggi Apple si è mostrata ben poco ricettiva alle richieste di Sun di implementare Java su iPhone , ma quest’ultima non sembra darsi per vinta. La posta in gioco, del resto, è rappresentata da una fetta del lucroso mercato delle applicazioni per il melafonino, mercato su cui Apple si è garantita il pieno controllo grazie all’App Store.

Proprio negli scorsi giorni la mamma di Java ha detto di essere ancora speranzosa sulla possibilità di raggiungere un accordo con Apple. E se tale accordo non dovesse mai arrivare, Sun ha rivelato che gli sviluppatori Java potranno sempre ricorrere ad un convertitore di codice di terze parti.

“Siamo pronti a collaborare con Apple alla realizzazione di una Java Virtual Machine per iPhone”, ha ribadito Eric Klein, vice president del Java marketing di Sun. “Nel frattempo, stiamo lavorando con Innaworks ad un progetto alternativo”.

Il progetto alternativo a cui fa riferimento Klein porta il nome di alcheMo for iPhone , ed è un software in grado di compilare i programmi Java 2 Micro Edition (J2ME) in applicazioni native per iPhone. Innaworks, la società che sta sviluppando questa soluzione, afferma che le applicazioni Java compilate con alcheMO potranno essere distribuite attraverso l’App Store di Apple.

“Inizialmente alcheMO si indirizzerà soprattutto agli sviluppatori di giochi”, ha spiegato la società. “Gli sviluppatori potranno utilizzare il nostro software per portare i loro titoli J2ME su iPhone e iPod Touch senza la necessità di alcuna modifica al codice o altro intervento manuale”.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • conigliosauro scrive:
    siti municipali italiani attaccati?
    Ma sono stati attaccati anche siti municipali italiani? si conosce qualche caso?
    • ThEViRuZ scrive:
      Re: siti municipali italiani attaccati?
      mi occupo dell'aggiornamento del sito assistenza.agenziadogane.it e al momento per quanto mi riguarda ha colpito solo un voce di menu che fa una semplice select su DB altri punti del sito che fanno la stessa identica cosa funzionano correttamente.
  • antonio scrive:
    La forza di Google
    Cercate su Google questo:inurl:select inurl:where inurl:%20Ci credo che è facile fare SQL Injection!Trovato su thedailywtf.com
    • unaDuraLezione scrive:
      Re: La forza di Google
      contenuto non disponibile
    • MeMedesimo scrive:
      Re: La forza di Google
      2o risultato: http://www.comune.livorno.it/toponomastica/Strada_Rubricaviecirc.asp?whichpage=20&pagesize=10&sqlQuery=SELECT+*++from+topo_vieconsuddivisione+where+vie_attrib1+%3C%3E+'0000'++and+trim(vie_attrib1)+%3C%3E+''++order+by+vie_attrib1%2Cvie_nomignolo%2Cvie_danumno ma veramente...... come ca22o si fa????????
  • biffuz scrive:
    SQL injection, ancora?
    Basta controllare l'input per evitarlo, e tutti i linguaggi hanno una funzione unica per farlo.Così imparate ad assumere ragazzini che hanno imparato a programmare su Topolino per pagarli poco...
    • .net scrive:
      Re: SQL injection, ancora?
      OleDbParameter di System.Data.OleDb, questo sconosciuto- Scritto da: biffuz
      Basta controllare l'input per evitarlo, e tutti i
      linguaggi hanno una funzione unica per
      farlo.
      Così imparate ad assumere ragazzini che hanno
      imparato a programmare su Topolino per pagarli
      poco...
  • systemax scrive:
    Secondo me il bug si trova...
    Secondo me il bug si trova su apache non su iis anche perchè sono riusciti ad infettare con un javascript il file js del mio sito, che non poteva essere vulnerabile a nessun attacco di injection, sono riusciti proprio ad entrare nei server come root in quanto il mio server è server linux e successivamente a scaricarsi i file e odificarli per poi rifare l'upload, deve essere una falla MOLTO GRAVE questa, se riesconoa fare tutto questo liberamente...
    • Miss K Lorina scrive:
      Re: Secondo me il bug si trova...
      Se il tuoi server è su Aruba il bug non è su Apache ma su come Aruba gestisce i permessi dei DB.Se invece non hai Aruba, allora c'è qualche fesseria (bella grossa) sullo script PHP che ti hanno attaccato, o in come il tuo server gestisce i permessi del DB.
      • systemax scrive:
        Re: Secondo me il bug si trova...
        il mio server è su aruba...perchè come gestisce aruba i permessi su db?
        • Nome e cognome scrive:
          Re: Secondo me il bug si trova...
          - Scritto da: systemax
          perchè come gestisce aruba i permessi su db?A pene di segugio! Ovvio no?
        • Miss K Lorina scrive:
          Re: Secondo me il bug si trova...
          Se non è cambiato nulla dall'ultima volta, l'utente che usi per interrogare il DB è lo stesso che ha diritto di vita e di morte sul DB stesso, il che è sbagliato.
          • gino scrive:
            Re: Secondo me il bug si trova...
            - Scritto da: Miss K Lorina
            Se non è cambiato nulla dall'ultima volta,
            l'utente che usi per interrogare il DB è lo
            stesso che ha diritto di vita e di morte sul DB
            stesso, il che è
            sbagliato.tanto per farla breve a chi capisce poco e niente (e non se ne accorge):alla prima sql injection sul database...auguri :D
          • systemax scrive:
            Re: Secondo me il bug si trova...
            Ma dal mio database non risulta nulla, e poi come fanno ad intaccare un file che con il database non c'entra nulla nel mio caso un file javascript, l'sql injection crea danni sul database non sul filesystem, esiste un esempio in cui questo è dimostrato?
          • gino scrive:
            Re: Secondo me il bug si trova...
            permessi mal settati a www-data e alle cartelle in cui tu puoi scrivere? permessi mal settati allo script php?è colpa degli amministratori di aruba ;)
          • systemax scrive:
            Re: Secondo me il bug si trova...
            credo proprio di si a questo punto...perchè io faccio il data filtering...solo che aruba scarica sempre la colpa su software di terze parti anche se il mio sito non ne ha :D
          • gmorse scrive:
            Re: Secondo me il bug si trova...
            scusate l'ignoranza ma sono un webmaster molto improvvisato. Hho un paio di siti con solo html e flash, e' possibile che anche in questi vi siano stati iniettati dei codice maligno - o malevolo como dir si voglia ?:D
          • unaDuraLezione scrive:
            Re: Secondo me il bug si trova...
            contenuto non disponibile
          • ... scrive:
            Re: Secondo me il bug si trova...
            Su Aruba adesso c'è MySQL 5. È vero che si usa sempre lo stesso user, ma è anche vero che questa versione permette di creare le VIEW, tabelle in sola lettura, con cui è possibile costruire le pagine pubbliche. Il che aumenta la sicurezza, è ovvio che bisogna sempre filtrare i dati.
  • Giulio Cesare scrive:
    Re: E' una "vulnerabilità" ASP/MSSQL...
    - Scritto da: olandese volante
    ... anche se Microsoft dice che non è una
    vulnerabilità.

    "That's not a bug, it's a feature!"

    In pratica, usando ASP e MSSQL, è possibile
    inviare più di un query al database in una solaE guardacaso se segui il link dell'articolo trovi un bell'esempio basato su PHP/Mysql. Fare polemica sempre e comunque, vero?
    • olandese volante scrive:
      Re: E' una "vulnerabilità" ASP/MSSQL...
      Dall'articolo:Usually only SQL Server allows query stacking, MySQL allows it also but not through a webapplication that uses mysql_query().Tradotto:Di solito soltanto SQL Server permette query multiple, anche MySQL lo permette ma non in un'applicazione web che usa mysql_query() .Guarda caso, se vuoi accedere ad un database MySQL da PHP, lo fai usando appunto mysql_query. Esiste anche il metodo mysqli_multi_query() ma in pratica viene usato molto raramente.Mi piace fare polemica, ma almeno leggo l'articolo, e se è il caso faccio un pò de ricerche aggiuntive, prima di farlo.-----------------------------------------------------------Modificato dall' autore il 28 aprile 2008 09.24-----------------------------------------------------------
      • Lemon scrive:
        Re: E' una "vulnerabilità" ASP/MSSQL...
        Modificato dall' autore il 28 aprile 2008 09.24
        --------------------------------------------------Scusa non capisco. Prima hai detto che era possibile solo su asp/mssql, poi viene fuori che e' possibile anche su php/mssql e adesso mi dici che tecnicamente e' fattibile anche su php/mysql perche' esiste la funzione per le query multiple (ma non molto utilizzata). Scusa ma c'e' una bella differenza dal tuo post iniziale, avevi detto che NON si poteva fare, era una feature presente solo su mssql, puoi spiegarti meglio?
        • Miss K Lorina scrive:
          Re: E' una "vulnerabilità" ASP/MSSQL...

          Scusa non capisco. Prima hai detto che era
          possibile solo su asp/mssql, poi viene fuori che
          e' possibile anche su php/mssql e adesso mi dici
          che tecnicamente e' fattibile anche su php/mysql
          perche' esiste la funzione per le query multiple
          (ma non molto utilizzata). Scusa ma c'e' una
          bella differenza dal tuo post iniziale, avevi
          detto che NON si poteva fare, era una feature
          presente solo su mssql, puoi spiegarti
          meglio?Su MSSQL è così di default e non è possibile disabilitare questo comportamento (query multiple), su PHP/MySQL invece di default non puoi fare query multiple, ma devi forzare il sistema a farle, quindi devi sapere quello che stai facendo, e magari se l'amministratore di sistema abilita questa funzionalità, perché non può proprio farne a meno (difficile che accada, ma tuttavia non impossibile), comunque imposta i permessi sul DB in maniera più accurata (permessi e utenti separati, solo per fare le SELECT con un utente pubblico, e INSERT/DELETE/UPDATE solo per un altro utente associato agli utenti con login, ad esempio).Insomma non per far polemica, ma il comportamento di PHP/MySQL mi sembra più logico, funzionale, sicuro e professionale.
      • maxxa scrive:
        Re: E' una "vulnerabilità" ASP/MSSQL...
        Per utilizzare semplicemente un "tool" come indicato nell'articolo e fare tutto in automatico credo proprio abbiano sfruttato la possibilità di fare querry multiple,comunque non c'è bisogno di fare più querry per attaccare un sito:una volta presi i permessi di amministratore ed entrati nell'area di amministrazione fai poi ciò che vuoi.....mssql o mysql che sia...
        • Miss K Lorina scrive:
          Re: E' una "vulnerabilità" ASP/MSSQL...
          Se puoi fare query multiple e l'amministratore di sistema è una "capra" (non ha cioè separato i permessi di SELECT da quelli di modifica del DB con utenti diversi), non ti serve entrare nell'area di amministrazione.Ad una SELECT accodi una INSERT o un UPDATE e fai col DB quello che vuoi.
          • unaDuraLezione scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            contenuto non disponibile
          • Miss K Lorina scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            Si, ovviamente. Ma un buon amministratore di sistema, imposta il tutto partendo dal presupposto che chi userà i suoi server sarà una capra.Poi pretende anche che chi scrive codice non lo scriva a pene di segugio, ma intanto si para il di dietro con una gestione dei permessi paranoica.Altrimenti a che serve un amministratore di sistema? Basta un picchio ad acqua che pigi sempre sul tasto "Y".
          • unaDuraLezione scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            contenuto non disponibile
          • gino scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            la complicità o la sbadataggine dei programmatori della web app ;)potrebbero aver scritto tutto "bene" ma se poi riesco a fare una sql injection...
          • unaDuraLezione scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            contenuto non disponibile
          • gino scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            ah già perchè anche il miglior programmatore del mondo non può creare un programma con dei bug vero?basta un minimo if, un
          • unaDuraLezione scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            contenuto non disponibile
          • rotfl scrive:
            Re: E' una "vulnerabilità" ASP/MSSQL...
            - Scritto da: gino
            ah già perchè anche il miglior programmatore del
            mondo non può creare un programma con dei bug
            vero?Non validare l'input lato server e' un errore MADORNALE. Non si tratta di "programmare con dei bug", si tratta di non aver neanche fatto dei test su quello che dovrebbe essere il PRIMO bug che si va a cercare. Non ci sono storie che tengano, non fare test su una cosa del genere equivale a non avere neanche le basi minime.
  • vavava scrive:
    Facile dare la colpa agli amministratori
    Facile dare la colpa agli amministratori con il CLOSE !!Ciao
    • unaDuraLezione scrive:
      Re: Facile dare la colpa agli amministratori
      contenuto non disponibile
      • gino scrive:
        Re: Facile dare la colpa agli amministratori
        colpa dell'amministratore che ha dato all'utente collegato a quella webapp il potere di modificare i dati invece che fare solo select
        • unaDuraLezione scrive:
          Re: Facile dare la colpa agli amministratori
          contenuto non disponibile
          • rotfl scrive:
            Re: Facile dare la colpa agli amministratori
            colpa dell'amministratore che ha dato

            all'utente collegato a quella webapp il potere
            di

            modificare i dati invece che fare solo

            select

            In questo caso, la colpa è di entrambi
            (programmatore e
            amministratore).
            La colpa del programmatore è aver permesso la SQL
            injection (che si evita con una riga di
            codice).
            La colpa dell'amministratore è ovvia.
            Dare la responsaiblità al solo amministratore è
            una cazzata
            galattica.
            Anche perchè SQL injection può essere usato anche
            per leggere dati importanti è l'amministratore
            non può farci
            nullaHai perfettamente ragione. E' assolutamente insensato dare la colpa solo all'amministratore del DB. E' molto, ma MOLTO piu' grave la colpa di chi ha creato l'applicazione web. Una SQL injection non fa danni solo con un UPDATE o un DROP, e chi afferma il contrario evidentemente non sa neanche di cosa parla.
        • rotfl scrive:
          Re: Facile dare la colpa agli amministratori
          - Scritto da: gino
          già -.-

          il mio programmatore deve creare una web app che
          restituisce solo dal database e non inserisce
          nulla

          semplice dirai, se il programmatore web non fa
          delle modifiche il database sarà al
          sicuro...

          NO!!!

          sql injection e mando una query che droppa tuttoMa cosa vai blaterando? Guarda che il programmatore che fa una web app appunto deve filtrare l'input!!! :@ Se il parametro passato come stringa e' ad esempio testo, se il programmatore fa un lavoro come si deve, non potremo mai dare un instruzione al DB di fare un drop!index.php?id=pippo%27%3Bdrop%20table%20tab--con un'applicazione web fatta come si deve la query risultaSELECT value FROM table WHERE id='pippo'; DROP TABLE tab--'mentre con un'applicazione web fatta coi piedi, risultaSELECT value FROM table WHERE id='pippo'; DROP TABLE tab--'nel primo caso il DB andra' a cercare una riga della tabella table in cui il valore del campo id e' pippo'; DROP TABLE tab-- , nel secondo caso andra' a cercare una riga della tabella table in cui il valore del campo id e' pippo e poi eseguira' DROP TABLE TAB .
  • MircoM scrive:
    relativamente a oracle
    quell'ultima frase su oracle buttata lì alla fine di un articolo che parla di attacchi SQL injection fa pensare ad una falla facilmente sfruttabile da remoto...in realtà le cose stanno diversamente. magari una precisazione sarebbe stata gradita...
Chiudi i commenti