La mia preoccupazione principale è la seguente:meteora codice XSS manomissioni
dal meteorite si basa su JavaScript, può essere modificata/manomesso @ lato client, così che cosa succede se cambio o di creare nuove collezioni e di partenza per spammare il db sarà solo @ lato client (solo memoria) o su entrambi i lati cioè: lato server.
l'input dell'utente viene cancellato da xss prima del salvataggio sul lato server ?.
Se si crea una nuova collezione sul lato client, il server avrà alcuna conoscenza di questo e, inoltre, non creerà il materiale necessario per modificare il lato server di database. I dati spammati saranno solo nella memoria lato client.
Trees = new Meteor.Collection("boom");
Meteor.Collection
Trees.insert({hi:"hi"});
"4b0d5ff2-058c-4041-849b-ce2e0d548160"
logging.js:30: insert failed: 404 -- Method not found
questo è corretto e per chiarire ulteriormente non ha conoscenza perché non è stato sottoscritto. A meno che non inizi a manomettere una collezione già esistente, non c'è ancora nulla da impedire che ciò accada. – Adgezaza
così per evitare il rinvenimento con la raccolta sottoscritta dovremmo gestire le sezioni critiche bloccando i metodi helper del database @ lato server come mostrato in [brito] (http://britto.co/blog/security_with_meteor) questo dovrebbe fare il trucco credo : 'Meteor.startup (function() { _.each ([/ ** collezioni nomi ** /], la funzione (raccolta) { _.each ([ 'inserto', 'update', ' rimuovere '], funzione (metodo) { Meteor.default_server.method_handlers [' /' + raccolta + '/' + metodo] = function() {}; }); }); }) Grazie a tutti. –
Vorrei anche sapere questo: ho visitato il sito Web per un po 'e mi sono interrotto una volta che ho letto che * tutto * è stato fatto in js. Non che io abbia qualcosa contro questo, ma preferisco almeno un po 'di sicurezza sul lato server per dormire bene la notte. –
Sono abbastanza sicuro che "Tutto è fatto in JS significa" da un punto di vista linguistico. C'è ancora separazione tra server e lato client. –