Pilvipalvelimella olevan nettisivun tekstin päivitys selaimella

[teele]

Pilvikoneella olevaa nettisivua pitäisi  muokata selaimella php:n avulla mutta luulisi olevan kyse niin pienestä asiasta, että siihen olisi jo tehty monia ohjelmaia.

Olisi hyvä, jos löytyisi joku yksinkertainen valmissovellus, jonka avulla voi omalla selaimella päivittää pilvikoneellla olevaa nettisivua ja tehdä uusia sivuja tai poistaa vanhoja.

Wordpressi voisi olla turhan rankka vaihtoehto ja pilvikonekin on ihan pieni muistin ja levytilan osalta eikä siinä ole mitään mysq:täkään.

Eli joku pikku php-scripti voisi olla ratkaisu, onko niistä kokemuksia tai voisiko joku suositella jotain sen tapaista.

[Jere Sumell]

Järkevämpi ratkaisu mielestäni on ensinnäkin yksi kone kehitysympäristöksi räätälöity järjestelmä, ja sitten paikllisesti ohjelman lähdekoodin luonti ja testiympäristössä ajo paikallisesti, jonka jälkeen voi siirtää valmiit tiedostot palvelimelle. Pilvialustat ei liene poikkeus siinä, etteikö sinnekin voisi uploadata tiedostoja. Toki voi, vaikka itse en ole minkään pilviresursseja tarjoavan firman asiakas tällä hetkellä toistaiseksi ainakan.

Näin olen itse päätynyt tähän , ja mahdollisesti sitten kehitysympäristö-linukka kaikkineen, niin netissä ei kanata olla sen kehitysympäristö-koneen kanssa.

Kääntöpuolella, jos suoraan palvelimella ohjelmoit sama mitä, scriptejä yms ja teet välitallennuksia, ne päivittyvät siellä reaaliajassa, ja sitten jos client-puolella asiakas tulee palveluusi tai saitillesi selaimella tai millä sitten sen kutsupyynön palvelimelle lähettääkään, niin voi tulla huono asiakaskokemus/tietoturvariski sinun puoleltasi, kun välitallenuksen jälkeen palvelu tai sivut ovat "keskeneräiset", mitä kannattaa julkaista vasta valmis toimiva paketti harkitusti kertalaakista. Eikö?

[_Pete_]

Eli joku pikku php-scripti voisi olla ratkaisu, onko niistä kokemuksia tai voisiko joku suositella jotain sen tapaista.

Tällainen kuulostaa hakkeri ystävälliseltä ratkaisulta.

[teele]

Sitten jos client-puolella asiakas tulee palveluusi tai saitillesi selaimella tai millä sitten sen kutsupyynön palvelimelle lähettääkään, niin voi tulla huono asiakaskokemus/tietoturvariski sinun puoleltasi

Tällainen kuulostaa hakkeri ystävälliseltä ratkaisulta

Juuri siitä hakkeriystävällisyydestä olen huolissani. Siksi yritinkin etsiä jo jonkun valmiiksi miettimää ratkaisua, jossa olisi mietitty, miten hakkeriystävällisyyttä voi pienentää.

Jääkö vielä paljon hakkeriystävällisyyttä, jos php tarkistaa, että syötettävä teksti ei sisällä muuta kuin ääkkösiä, numeroita, rivinvaihdon ja pisteen ja pilkun. Tarkoituksena olisi vain syöttää selaimella tavallista tekstiä.

[_Pete_]

Sitten jos client-puolella asiakas tulee palveluusi tai saitillesi selaimella tai millä sitten sen kutsupyynön palvelimelle lähettääkään, niin voi tulla huono asiakaskokemus/tietoturvariski sinun puoleltasi

Tällainen kuulostaa hakkeri ystävälliseltä ratkaisulta

Juuri siitä hakkeriystävällisyydestä olen huolissani. Siksi yritinkin etsiä jo jonkun valmiiksi miettimää ratkaisua, jossa olisi mietitty, miten hakkeriystävällisyyttä voi pienentää.

Jääkö vielä paljon hakkeriystävällisyyttä, jos php tarkistaa, että syötettävä teksti ei sisällä muuta kuin ääkkösiä, numeroita, rivinvaihdon ja pisteen ja pilkun. Tarkoituksena olisi vain syöttää selaimella tavallista tekstiä.

Kysehän on siitä miten autentikointi on tähän hoidettu. Ketään täysi järkinen ei varmaankaan nyky päivänä pidä tuollaista auki niin että sitä voi käyttää kuka vaan ilman tunnistautumista.

[teele]

Kysehän on siitä miten autentikointi on tähän hoidettu. Ketään täysi järkinen ei varmaankaan nyky päivänä pidä tuollaista auki niin että sitä voi käyttää kuka vaan ilman tunnistautumista.

Koko ajan on ollut ajatuksena, että muokattaessa pitäisi ensin tunnistautua käyttäjänimellä ja salasanalla. Asia tuntui niin itsestään selvältä, että se taisi unohtua manita. Tarkoituksena ei ole hakkeriystävällisyys, vaan helpottaa luvallisen käyttäjän tavallisen tekstin syöttämistä sivulle.

Jos salasana ja käyttäjätunnus ovat vaikka php-koodisssa, niiden ei pitäisi näkyä kenellekään. Mutta pääseekö osaava hakkeri niihin silti jollain yleisesti tunnetulla tavalla käsiksi. Käyttäjän syöte mennee kai salattuna https-sivulle, riittääkö se.

Kokemusta tällaisesta sivusta ei ole, enkä haluaisi tehdä turhaa työtä, jos kaikki hakkerit kuitenkin pääsisivät tekemään omia juttujaan sivulle tai palvelimelle sivun kautta.

[Tomin]

Itse varmaan toteuttaisin autentikaation HTTP:n digest-metodilla. Silloin se säädetään web-palvelimeen, eikä PHP:n tarvitse välttämättä välittää siitä ollenkaan. Näytettäviä sivuja ei tietenkään tarvitse suojata, jos ei halua, mutta PHP-skripti tai ehkä vielä mieluummin sen koko alihakemisto pitää toki suojata.

https://en.wikipedia.org/wiki/Digest_access_authentication
https://httpd.apache.org/docs/2.4/howto/auth.html

[Jere Sumell]

Jos salasana ja käyttäjätunnus ovat vaikka php-koodisssa, niiden ei pitäisi näkyä kenellekään. Mutta pääseekö osaava hakkeri niihin silti jollain yleisesti tunnetulla tavalla käsiksi. Käyttäjän syöte mennee kai salattuna https-sivulle, riittääkö se.

Kovakoodaus, hard coding on vihoviimeinen, että missään olisi ainakaan mitään kirjautumistietoja kovakoodattuna muuttujissa. Se on selvää, että ne joku nappaa ennen pitkää.

Tiedon validointi tosiaan yksi verkkosovellus-turvallisuuspuolella puolustusnäkökulmasta, mitä kyselit, jos syötteenä pistää kelpaamaan vain halutut asiat, eli käytää valkoista listaa. Säännölliset lausekkeet ja voi olla aika kinkkisiä joskus.

Kuulostaa lähinnä siltä, että jokin sisällönhallinta-ratkaisu voisi olla aiheellista asentaa sivujen moottoriksi tuosta päätellen, mitä kerroit, että pitäisi olla jokin ratkaisu, että voi tekstiä helposti syöttää ja päivittää sivulle.

PHP -koodi tosiaan ei näy selaimen "Näytä sivun lähdekoodi" -osiossa, mutta sitten on lähdekoodin obfuskointi yksi keino ja välttää koodiin kiinni pääsemistä, sen lisäksi, että voi koneellisesti tiivistää Javascriptit/html:t yms, vaikka nekin saa koneellisesti luettavampaan muotoon käänteisenä.

En ole perillä tiedon obfuskoinnista niin paljon, saako sitä käänteisenä ihmiselle luettampaan muotoon tai mitä niihin objuskointi-salaus-algoritmeihin liittyy.

[_Pete_]

Jos salasana ja käyttäjätunnus ovat vaikka php-koodisssa, niiden ei pitäisi näkyä kenellekään. Mutta pääseekö osaava hakkeri niihin silti jollain yleisesti tunnetulla tavalla käsiksi. Käyttäjän syöte mennee kai salattuna https-sivulle, riittääkö se.

Tässä chat-gpt "mielipide" asiasta:

Storing authentication usernames and passwords directly in your PHP code is generally not secure and is not a recommended practice. There are several reasons why this approach is insecure:

1. Hardcoding Credentials: Storing usernames and passwords in your code means they are easily accessible to anyone who can view the source code. This is a security risk, especially if your code is publicly accessible.

2. Risk of Code Repository Exposure: If you're using a version control system like Git, it's easy to accidentally commit and push your credentials to a public repository, making them available to the world.

3. Password Security: Storing passwords in plaintext is a significant security risk. Passwords should be hashed and salted, using secure, well-established cryptographic techniques, which can't be done if they are hardcoded.

4. Maintenance Challenges: Hardcoded credentials are difficult to manage because they require code changes every time a password needs to be updated. This can lead to human errors and make it challenging to maintain your application.

5. Limited Scalability: Storing credentials in your code restricts the flexibility to use different credentials for different environments (e.g., development, testing, production) without code modification.

Instead, consider the following best practices for secure authentication:

1. Use a Configuration File: Store credentials in a separate configuration file (e.g., a JSON, INI, or environment variable file). This file should be excluded from version control and kept separate from your codebase.

2. Hash Passwords: When working with user passwords, use a secure password hashing library (e.g., PHP's password_hash()) to securely store and verify passwords.

3. Implement User Authentication: Use a user authentication system or framework (e.g., OAuth, JWT, or a dedicated library) that provides secure methods for handling user authentication.

4. Environment Variables: In a production environment, consider storing sensitive information like database credentials in environment variables, which can be securely managed at the server level.

5. Least Privilege: Ensure that your application and database have the minimum necessary permissions. Avoid using overly permissive accounts.

6. Regularly Update Credentials: Periodically update passwords and rotate access credentials to maintain security.

Remember that security is an ongoing process, and it's essential to follow best practices to protect sensitive information and user data. Hardcoding credentials in your PHP code should be avoided to maintain the security and integrity of your application.

[teele]

Kysymyksessä oleva sivu on pienen yhteisön nettisivu. Yhteisön osaavimmat it-tyypit Kiia, Miia ja Tiia ovat yhdessä  vastuussa siitä, että sivu on ajan tasalla. He päivittävät kommentit päivän hauskimmista kissavideoista, arviot kokeilemistaan kätsäleivonnaisistaan ja mielipiteensä uusimman sarjan ihquimmasta näyttelijästä selaimellaan yhteisön sivulle. Muilla ei ole oikeuksia sivun muokkaamiseen.

Muuta versionhallintaa sivulla ei ole.

Chatgpt sanoo kohdassa 1, että kuka tahansa, joka näkee sivun (php-)koodin voi sitten muokata sivua. Mutta miksi php-koodi näkyisi ulkopuolisille, vai saako sen osaava hakkeri jollain tavalla kaivetuksi esille.

Kohdassa 2 käsitellään versionhallintaa. Sivua ei hallita sen enempää, ainakaan selaimen kautta.

Kohdassa 3 puhutaan selvätekstisistä salasanoista, mistä tullaan taas kohtaan 1 eli onko php-koodi turvassa, kun sivua ei muokata muuta kuin päivitettävien tekstien osalta ja syötteenä voi mennä vain ääkkösiä, numeroita, rivinvaihto ja piste ja pilkku. Php tarkistaa aina syötteen.

Kohdassa 4 puhutaan salasanojen päivittämisestä. Niitä ei selaimen kautta päivitetä.

Kohdassa 5 puhutaan eri salasanoista eri ympäristöissä. Päivittäjät päivittävät sivun tekstiä omilla selaimillaan. Muita ympäristöjä ei ole.

Salasanojen hajautuksen (hashing) ehkä osaisin tehdä, mutta muuten haluaisin pitää asiat mahdollisimman pieninä.

Säikeen alkukysymysessä ollut toive uusien sivujen lisäämisestä ja vanhojen poistamisesta kannattaa ehkä tässä vaiheessa jättää myöhemmäksi, kun valmiita ratkaisuja siihen ei ollut jo valmiina.

Ehkä tärkein kysymys on nyt se php-koodin mahdollinen näkyminen. Jos se on mahdollisesti näkyvissä hakkerille, asiat mennevät vähän mutkikkaammaksi?