Tópico da Programação (desenvolvimento de software)

[Nuno156]

Heim? Esses exploits que linkaste existem porque o phpMyAdmin é open source, tal como podias mostrar exploits para o Wordpress, presta shop, phpbb (e outros x forum softwares), então agora o open source está mais imune a exploits lol? Quer dizer, tens o código exposto ao mundo, quem quiser explorar asério bugs com software open source vai reportá-los? E mesmo sendo reportados, quantos bugs não são corrigidos?

Eu sou completamente a favor do open source, mas sei identificar que todo o software open está muito mais exposto a exploits, até porque todos os meses somos bombardeados em qualquer software open source de nome, todo o santo dia posso ir aos logs ver n crawlers a tentar explorar versões antigas do wordpress e afins.

Essa da equipa do phpMyAdmin também não percebo, é até a primeira vez que estou a ouvir criticas ao pMA, todos os developers que me cruzei até agora usam o pMA e nunca ouvi nada... o pMA está no github e qualquer gajo pode fazer o que bem entender com o projecto, já nem é um projecto de uma só equipa. Gostava de entender melhor o que tens contra o pMA (estou a falar asério! pode ser que possa aprender alguma coisa).

Percebes bué disto... NOT!

[]

Olha, até me dou ao luxo de usar a Microsoft como fonte:

Is Security by Obscurity a valid approach?

Security by obscurity is, in a nutshell, a violation of Kerckhoffs' Principle, which holds that a system should be secure because of its design, not because the design is unknown to an adversary. The basic premise of Kerckhoffs' Principle is that secrets don't remain secret for very long.

[]

As a very good example, take the Windows NT® LAN Manager (NTLM) authentication protocol, which was initially considered a design secret. In order to implement the Samba interoperability product for UNIX-based operating systems, the Samba team had to reverse engineer the protocol. The result was the most comprehensive documentation on NTLM available (monyo.com/technical/samba/translation/ntlm.en.html) as well as the discovery of a number of bugs. Because so much of security grew out of cryptography, and so many secret designs have been revealed, many security practitioners believe all of Information Security should follow Kerckhoffs' Principle.

Obviamente, não poderia faltar a Wikipedia:

Security through obscurity - Wikipedia, the free encyclopedia

Security through obscurity is generally a pejorative term referring to a principle in security engineering, which attempts to use secrecy of design or implementation to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that if the flaws are not known, then attackers will be unlikely to find them. (...)
Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of simplicity. The United States National Institute of Standards and Technology (NIST) specifically recommends against security through obscurity in more than one document. Quoting from one, "System security should not depend on the secrecy of the implementation or its components."
(...)
Because its source code is public knowledge, open source software is less fit to use security through obscurity.

Governo britânico:

https://www.gov.uk/government/uploa...file/78967/OSS_Toolkit_Security_Note_v1.0.pdf

1. Open source, as a category, is no more or less secure than closed proprietary software.
All software, including open source and closed proprietary, will have vulnerabilities. Individualsoftware products, regardless of category, will have strengths and weaknesses in securitycharacteristics such as provenance, quality, support, and vulnerability management. Given the rangeof vulnerabilities and diversity of exploits, on balance, neither category is considered more or lesssecure than the other.

Portanto, dizer que:

Se formos por aí, mais vale não instalar nada open source

Não faz qualquer sentido.

Isto não tem NADA a ver com Open Source. Tem simplesmente a ver com quem desenvolve.

E sim, a haver diferença é a favor do Open Source.
É muito mais fácil para os White Hats debruçarem-se sobre código aberto, do que código
sobre o qual tenham de fazer reverse engineering. Quem tem mais interesse em descobrir
vulnerabilidades em código fechado é quem tem a lucrar (€€€€) com essas vulnerabilidades.
Ou seja, tem em mira um retorno (€€€€) para o tempo investido em reverse engineering.

E não estamos a falar em reportar bugs, estamos a falar de CVE. E os CVE têm prioridade,
lá está, quando a equipa do projecto sabe o que anda a fazer.


Quanto aos logs dos crawlers...
[]

Experimenta ir antes aos logs das firewalls e IDS/IPS. E não estou a falar de firewalls dos
servidores, estou a falar de hardware específico. Depois diz-me se a maioria dos ataques é
sobre FOSS.
[]

Top Intrusion Attacks
E ordena por risco (coloca o risco mais elevado primeiro), depois diz quanto FOSS é que lá está.
[]

Quanto ao PHPMyAdmin... tenho zero contra... e ainda menos a favor. Coloca mais problemas
do que aqueles que resolve. É uma falha de segurança. Grande. Muito grande. Ninguém no
seu perfeito juízo usa uma ferramenta desse tipo. Idem para o cPanel. Idem para todas essas
ferramentas de "administração" para "administradores".

 

[Nuno156]

Talvez eu não esteja a compreender.

O software não deve ter acesso às suas bases de dados? Não deve ter permissão para mexer nos registos?

Repito:
- O que consideras gestão (administração) de uma base de dados?

Uma aplicação cria tabelas?
Uma aplicação altera tabelas?
Uma aplicação cria índices?
Uma aplicação cria utilizadores?

As aplicações só devem ter acesso a DML e SQL.
Nunca devem ter acesso a DDL, muito menos DCL.

E mesmo o acesso a DML e SQL deve ser muito bem definido.

Todas as ferramentas que tenham acessos privilegiados não devem estar acessíveis a
qualquer um, muito menos de fora da Intranet. Para aceder de fora, só via VPN.

 

[Titanio]

Repito:
- O que consideras gestão (administração) de uma base de dados?

Uma aplicação cria tabelas?
Uma aplicação altera tabelas?
Uma aplicação cria índices?
Uma aplicação cria utilizadores?

As aplicações só devem ter acesso a DML e SQL.
Nunca devem ter acesso a DDL, muito menos DCL.

E mesmo o acesso a DML e SQL deve ser muito bem definido.

Todas as ferramentas que tenham acessos privilegiados não devem estar acessíveis a
qualquer um, muito menos de fora da Intranet. Para aceder de fora, só via VPN.

Criar tabelas: Não
Alterar tabelas: Sim
Criar índices: Sim
Criar utilizadores: Nim (depende de vários factores)

Quanto ao bold, é óbvio, onde se inclui a criação de tabelas, que devem preferencialmente estar limitadas à máquina local.

 

[Ironsmith]

1. Usar a Microsoft e open source na mesma frase já é mau, fazer quote a uma opinião dessa fonte ao universo open source... então pronto.

2. Começas a martelar como se alguém aqui defendesse segurança através de obscuridade, não sei bem porquê, maçãs e laranjas.

3. Menos smilies.

4. Menos cores (wtf, de repente text a bold, depois vermelho, depois azul)

Não sei bem porque vieste reagir assim, ninguem te veio aqui chamar nomes, todas as tuas quotes não são para aqui chamadas... sim, o open source é inseguro, sim o contrário também é... o que eu disse no meu primeiro post é uma resposta directa ao teu link - cenas que os script kiddies usam e lançam pela net com nomes do tipo "romenian top leet hacker cenas". Eu mencionei o OPEN SOURCE porque tu linkaste um site que lista exploits para todo e qualquer software OPEN SOURCE.

A imagem das top intrusions é completamente escusada, acabas por mudar o tema do tópico completamente... se queres entrar por esse espectro já não estamos a falar da mesma coisa. Um gajo a falar de código (é o tópico da programação...) e de repente apareces a falar de ataques ao hardware...

Depois há o phpMyAdmin (finalmente estamos a falar de alguma coisa em comum!), não percebo porque dizes ser assim uma falha tão grande de segurança, por onde passei sempre foi uma ferramenta valiosa, seja em que empresa ou projecto, em todos os projectos que estive inserido no mundo php, sempre foi usada e nunca nenhum developer se queixou (e os developers são sempre pessoas dificeis, a prova está no teu post []).

Agora asério...

As tuas quotes sinceramente não percebi, mas alguém esteve a defender código por obscuridade? Eu estou a falar puramente de numeros homem, quantas instalações de software open source são diariamente exploited em 24 horas de internet? Tu ainda me dizes que depente da equipa, mas tu confias em alguma equipa open source? Consegues arranjar exemplos de projectos open source em escala grande que consigas defender? De certeza que nunca foram exploited?

Um gajo que não quer usar o phpMyAdmin porque "Coloca mais problemas do que aqueles que resolve", então sff diz-me, que software open source na web vale a pena usar?

Boa noite, e calma..

 

[Nuno156]

Criar tabelas: Não
Alterar tabelas: Sim
Criar índices: Sim
Criar utilizadores: Nim (depende de vários factores)

Quanto ao bold, é óbvio, onde se inclui a criação de tabelas, que devem preferencialmente estar limitadas à máquina local.

Uma aplicação que ALTERA TABELAS?!
Não estou a falar de alterar DADOS, estou a falar de alterar TABELAS.

Criação de índices pela aplicação?!
Para quê? Isto é dBase? Clipper?

Uma aplicação a criar utilizadores no motor?!
Não estou a falar de utilizadores da aplicação (registos na BD). Estou a
falar de utilizadores mesmo da base de dados. É coisa que não se faz.
Até podes ter utilizadores da aplicação com contas na BD (depende do
tipo de aplicação), mas não pode de modo algum ser a aplicação a
criá-los.

http://docforge.com/wiki/Web_application/Security

• Secure the database itself by limiting connection sources, user accounts, and permissions. Generally, create the most restrictive database environment possible while still allowing the application to function.
  • Set the database server to only accept connections from the web application server. Even if the server has a firewall, the database software itself should only be listening to connections from the web application.
  • Do not create database user accounts for each web application user (when it's not absolutely necessary). Create one user account to always be used by the application. Handle user authentication at the application level.
  • This single application database user should only have the minimum amount of permissions it requires. For example, do not allow the web application database user to create tables, drop tables, or alter grants if it's not required. Never use the database's root or super-user account for a web application; these are only appropriate for system administrators.
  • Consider running all queries through stored procedures and not granting the database user any permissions other than execution of those stored procedures. This will greatly restrict the abilities of the database user.

Basic Security Practices for Web Applications

Access Databases Securely

---

Databases typically have their own security. An important aspect of a secure Web application is designing a way for the application to access the database securely. Follow these guidelines:

• Use the inherent security of your database to limit who can access database resources. The exact strategy depends on your database and your application:
  
  • If practical in your application, use integrated security so that only Windows-authenticated users can access the database. Integrated security is more secure than passing explicit credentials to the database.
    
  • If your application involves anonymous access, create a single user with very limited permissions, and perform queries by connecting as this user.
• Do not create SQL statements by concatenating strings that involve user input. Instead, create a parameterized query and use user input to set parameter values.
  
• If you must store a user name and password somewhere to use as the database login credentials, store them in the Web.config file and secure the file with protected configuration. For details, see Encrypting Configuration Information Using Protected Configuration.

Basicamente, uma aplicação cujo propósito não seja exclusivamente administrar uma
base de dados, nunca deve ter acesso a administrar uma base de dados. Não se mistura
administração com utilização numa mesma aplicação.

 

[Titanio]

Quando me referia a alterar tabelas, referia-me aos dados, como é evidente.

Quanto aos utilizadores, não me referia aos acessos às dbs e sim ao acesso de utilizadores às aplicações.

Resumindo:
Tudo quanto diga respeito ao motor, é claro que só com acesso de administração. Tanto a criação de tabelas como de users com acesso ao motor devem estar restritas apenas localmente.

As aplicações apenas deverão ter exclusivamente acesso a actualizações das dbs (dados!). Excepcionalmente, como pode acontecer em actualizações, poderão ter acesso de administração.

 

[Nuno156]

1. Usar a Microsoft e open source na mesma frase já é mau, fazer quote a uma opinião dessa fonte ao universo open source... então pronto.

2. Começas a martelar como se alguém aqui defendesse segurança através de obscuridade, não sei bem porquê, maçãs e laranjas.

3. Menos smilies.

4. Menos cores (wtf, de repente text a bold, depois vermelho, depois azul)

Não sei bem porque vieste reagir assim, ninguem te veio aqui chamar nomes, todas as tuas quotes não são para aqui chamadas... sim, o open source é inseguro, sim o contrário também é... o que eu disse no meu primeiro post é uma resposta directa ao teu link - cenas que os script kiddies usam e lançam pela net com nomes do tipo "romenian top leet hacker cenas". Eu mencionei o OPEN SOURCE porque tu linkaste um site que lista exploits para todo e qualquer software OPEN SOURCE.

A imagem das top intrusions é completamente escusada, acabas por mudar o tema do tópico completamente... se queres entrar por esse espectro já não estamos a falar da mesma coisa. Um gajo a falar de código (é o tópico da programação...) e de repente apareces a falar de ataques ao hardware...

Depois há o phpMyAdmin (finalmente estamos a falar de alguma coisa em comum!), não percebo porque dizes ser assim uma falha tão grande de segurança, por onde passei sempre foi uma ferramenta valiosa, seja em que empresa ou projecto, em todos os projectos que estive inserido no mundo php, sempre foi usada e nunca nenhum developer se queixou (e os developers são sempre pessoas dificeis, a prova está no teu post []).

Agora asério...

As tuas quotes sinceramente não percebi, mas alguém esteve a defender código por obscuridade? Eu estou a falar puramente de numeros homem, quantas instalações de software open source são diariamente exploited em 24 horas de internet? Tu ainda me dizes que depente da equipa, mas tu confias em alguma equipa open source? Consegues arranjar exemplos de projectos open source em escala grande que consigas defender? De certeza que nunca foram exploited?

Um gajo que não quer usar o phpMyAdmin porque "Coloca mais problemas do que aqueles que resolve", então sff diz-me, que software open source na web vale a pena usar?

Boa noite, e calma..

Cores...
O azul não é meu, são links. É o teu browser que mete isso a azul.
Vermelho: a parte mais relevante.
Bold: partes importantes.



Quanto a eu ter colocado um link para um site que lista exploits de Open Source...
deu para ficar a perceber que não sabes o que é um CVE. E que percebeste muito
menos o que é o site.

Ora vê lá melhor:
Microsoft : Products and vulnerabilities
Microsoft Windows Server 2008 : CVE security vulnerabilities, versions and detailed reports
Microsoft Windows 7 : CVE security vulnerabilities, versions and detailed reports
Microsoft Windows 8 : CVE security vulnerabilities, versions and detailed reports
Microsoft Windows 8.1 : CVE security vulnerabilities, versions and detailed reports

Quanto ao que é um CVE:
Common Vulnerabilities and Exposures - Wikipedia, the free encyclopedia



Quanto aos ataques ao hardware, mais uma vez dá para compreender que estás
a falar muito para além do que sabes. Eu NÃO falei em ataques ao hardware, falei
em VER os LOGS registados nas protecções em hardware. É que o que vês nos logs
de um servidor HTTP é um grão de areia. Enfim... Sinceramente, nem sei para que
estou aqui a perder tempo.

Quanto a developers se queixarem de ferramentas de administração, mais uma vez
é de quem está mesmo fora disto. E não sou developer.



Esconder o código fonte (código fechado) é o quê, então? Não é security by obscurity?
É batatas?

Ou seja, dizes que FOSS tem muitas vulnerabilidades por ser aberto, logo o fechado
tem menos, porque está obscuro. Se isto não é security by obscurity, é o quê?
Cogumelos?



Quantas instalações são alvo?!
[]

Não deves ter visto a imagem que eu coloquei, está visto. Os sistemas mais atacados
são Windows, não são FOSS. Mais, quem ataca WordPress e afins são os pseudo-hackers,
ou seja, o clube dos meninos do "deface".



Quanto a confiar em equipas, vai ver os CVE existentes para cada projecto. Depois talvez
chegues lá.



Quanto a software Open Source que vale a pena usar... é aos pontapés. Tanto assim é,
que o que eu uso mais é Open Source. Aliás, é muito raro usar qualquer coisa que não
seja Open Source. Microsoft uso ZERO. Até o OS X é baseado em Open Source.
Apple - Open Source
Darwin (operating system) - Wikipedia, the free encyclopedia



E sim, tenho que ter calma, porque só trabalho nisto há 25 anos, por isso posso estar
enganado no que estou a afirmar.

 

[Cheires]

Quando me referia a alterar tabelas, referia-me aos dados, como é evidente.

Quanto aos utilizadores, não me referia aos acessos às dbs e sim ao acesso de utilizadores às aplicações.

Resumindo:
Tudo quanto diga respeito ao motor, é claro que só com acesso de administração. Tanto a criação de tabelas como de users com acesso ao motor devem estar restritas apenas localmente.

As aplicações apenas deverão ter exclusivamente acesso a actualizações das dbs (dados!). Excepcionalmente, como pode acontecer em actualizações, poderão ter acesso de administração.

Epá, tabelas são tabelas, dados são dados, não são nem podem ser a mesma coisa.

As aplicações não podem ter acessos de administração. Se tem... é o caminho inteiro para dar barraca da grossa (e repara que não escrevi "é meio caminho").

As aplicações só têm acesso a dados, podendo altera-los ou não.

As actualizações das BD? Estás a referir-te ao quê? às versões do motor de BD, ou à alteração de dados?

E volto a repetir, acessos de administração só locais e de preferência por linha de comandos, e pelo administrador do sistema.

 

[Nuno156]

Quando me referia a alterar tabelas, referia-me aos dados, como é evidente.

Quanto aos utilizadores, não me referia aos acessos às dbs e sim ao acesso de utilizadores às aplicações.

Resumindo:
Tudo quanto diga respeito ao motor, é claro que só com acesso de administração. Tanto a criação de tabelas como de users com acesso ao motor devem estar restritas apenas localmente.

As aplicações apenas deverão ter exclusivamente acesso a actualizações das dbs (dados!). Excepcionalmente, como pode acontecer em actualizações, poderão ter acesso de administração.

Então pronto: Não fazes gestão (administração) da BD na aplicação.

Ou seja, a aplicação não executa DCL nem DDL. Executa apenas DML e SQL.

O PHPMyAdmin é essencialmente para administrar via interface web uma
base de dados em MySQL. Ou seja DCL e DDL.

 

[Nuno156]

Epá, tabelas são tabelas, dados são dados, não são nem podem ser a mesma coisa.

As aplicações não podem ter acessos de administração. Se tem... é o caminho inteiro para dar barraca da grossa (e repara que não escrevi "é meio caminho").

As aplicações só têm acesso a dados, podendo altera-los ou não.

As actualizações das BD? Estás a referir-te ao quê? às versões do motor de BD, ou à alteração de dados?

E volto a repetir, acessos de administração só locais e de preferência por linha de comandos, e pelo administrador do sistema.

Ora aí está.

Já agora, parafraseando o Cheires... PHPMyAdmin é caminho inteiro para dar barraca da grossa.

Tipo...
Um gajo instala um servidor com um Minimal Install.
Por razões de segurança, por omissão, a firewall só deixa passar SSH depois de instalado.
Depois instala PHPMyAdmin, cPanel e outras tretas... Brilhante!
[] [] []

 

[Titanio]

...

Tudo quanto diga respeito ao motor, é claro que só com acesso de administração. Tanto a criação de tabelas como de users com acesso ao motor devem estar restritas apenas localmente.

...

...

O PHPMyAdmin é essencialmente para administrar via interface web uma
base de dados em MySQL. Ou seja DCL e DDL.

No meu ponto de vista, estas situações são incompatíveis.

 

[Nuno156]

No meu ponto de vista, estas situações são incompatíveis.

Exacto.
Por isso é que eu estava ali às "turras" com o Ironsmith.

O PHPMyAdmin é um problema à espera de acontecer.

 

[Ironsmith]

Bem, ao Nuno já não vale a pena responder, uma coisa é não perceber, outra é não querer que os outros percebam - seja de que forma for.

Titanio, se estás a começar no mundo do php e do desenvolvimento web no geral, não há problema nenhum em usar a ferramenta phpMyAdmin, desde que não vás sacar uma versão qualquer de 2008 estás protegido contra 99% dos casos, e tendo em conta que és principiante, provavelmente não vais trabalhar num projecto que tenha uma importancia tão grande em que seja necessário outra solução. O phpMyAdmin foi sempre uma ferramenta essencial por onde passei, sempre. Simplesmente auxilia demasiado para ser ignorada. Repara que ninguem te deu aqui alternativas, mas secalhar há por aí malta (wink wink) que acha que deves ser tu a construir o teu próprio phpMyAdmin, ou talvez nem usar software deste tipo! Depois diz aí se consegues adiantar muito trabalho no dia a dia. Se quiseres estar totalmente seguro só tens uma solução: não trabalhar nesta área, assim estás sempre seguro . Mas se queres a minha opinião honesta do que se discutiu aqui: acho realmente crasso ter malta a dizer a um novato para não usar o phpMyAdmin, não só porque os problemas de segurança actuais existentes não te vão afectar, mas também porque ao não usares uma ferramenta destas só vais atrasar a tua aprendizagem, depois há outras razões, como um qualquer empregador esperar que saibas usar dita ferramenta e a resposta "não uso, não é seguro!!" não pegar.

Agora se me dás licença, tenho de me ir embora porque de aqui a nada vou levar mais uns tiros de smilies manhosos e quotes irrelevantes ao tema.

 

[Nuno156]

Bem, ao Nuno já não vale a pena responder, uma coisa é não perceber, outra é não querer que os outros percebam - seja de que forma for.

Titanio, se estás a começar no mundo do php e do desenvolvimento web no geral, não há problema nenhum em usar a ferramenta phpMyAdmin, desde que não vás sacar uma versão qualquer de 2008 estás protegido contra 99% dos casos, e tendo em conta que és principiante, provavelmente não vais trabalhar num projecto que tenha uma importancia tão grande em que seja necessário outra solução. O phpMyAdmin foi sempre uma ferramenta essencial por onde passei, sempre. Simplesmente auxilia demasiado para ser ignorada. Repara que ninguem te deu aqui alternativas, mas secalhar há por aí malta (wink wink) que acha que deves ser tu a construir o teu próprio phpMyAdmin, ou talvez nem usar software deste tipo! Depois diz aí se consegues adiantar muito trabalho no dia a dia. Se quiseres estar totalmente seguro só tens uma solução: não trabalhar nesta área, assim estás sempre seguro . Mas se queres a minha opinião honesta do que se discutiu aqui: acho realmente crasso ter malta a dizer a um novato para não usar o phpMyAdmin, não só porque os problemas de segurança actuais existentes não te vão afectar, mas também porque ao não usares uma ferramenta destas só vais atrasar a tua aprendizagem, depois há outras razões, como um qualquer empregador esperar que saibas usar dita ferramenta e a resposta "não uso, não é seguro!!" não pegar.

Agora se me dás licença, tenho de me ir embora porque de aqui a nada vou levar mais uns tiros de smilies manhosos e quotes irrelevantes ao tema.

I rest my case.

Quanto ao resto, principalmente o que está a BOLD, mais uma vez é de quem não
sabe do que está a falar. Provas? Estão aqui:
MySQL :: MySQL Workbench 6.0

Para quê fazer uma ferramenta idiota chamada PHPMyAdmin, se existe uma feita
de fonte oficial, e sem os problemas de segurança inerentes à exposição de tarefas
administrativas via HTTP.

Sinceramente...
[8b] [8b] [8b]

 

[Ironsmith]

I rest my case.

Quanto ao resto, principalmente o que está a BOLD, mais uma vez é de quem não
sabe do que está a falar. Provas? Estão aqui:
MySQL :: MySQL Workbench 6.0

Para quê fazer uma ferramenta idiota chamada PHPMyAdmin, se existe uma feita
de fonte oficial, e sem os problemas de segurança inerentes à exposição de tarefas
administrativas via HTTP.

Sinceramente...
[8b] [8b] [8b]

Ou seja, na tua opinião o Workbench só apresenta vantagens! Pronto, agora também vou ser cowboy, I rest my case!

Vou ligar agora o Workbench, pode ser que hoje funcione e consiga correr mais que uma query antes do exe morrer na praia.

edit:
bam, não deu. Mas posso ir experimentar ali na minha distro de linux favorita, oops, não funca.

Eu nem sei porque estamos a discutir, http://www.cvedetails.com/vulnerability-list/vendor_id-185/Mysql.html

Mais vale é nem usar o MySQL! []

 

[ravager]

Eu para mysql só quero o workbench.

O phpmyadmin ainda o usei, mas chegava a um ponto em que se tornava muito limitado em algumas coisas, tipo editar directamente dados na tabela, mexer em objectos tipo stored procedures, exportar e importar grandes volumes de dados, gerir directamente a bd.. etc etc.

 

[Nuno156]

Ou seja, na tua opinião o Workbench só apresenta vantagens! Pronto, agora também vou ser cowboy, I rest my case!

Vou ligar agora o Workbench, pode ser que hoje funcione e consiga correr mais que uma query antes do exe morrer na praia.

edit:
bam, não deu. Mas posso ir experimentar ali na minha distro de linux favorita, oops, não funca.

Eu nem sei porque estamos a discutir, Mysql : Security vulnerabilities

Mais vale é nem usar o MySQL! []

[] [] []

Já deu para perceber o que percebes de segurança. Nada.
As vulnerabilidades são cumulativas.

Ou seja, tu precisas de um servidor para o objectivo X. Portanto, só deves
instalar o estritamente necessário para cumprir o objectivo X. Nem mais,
nem menos.

Se o objectivo é ter um servidor de base de dados, instalas APENAS o motor
da base de dados. E vives APENAS com as vulnerabilidades desse motor.

Quando instalas MySQL + PHPMyAdmin + Apache + PHP (e tudo o necessário
para correr o PHPMyAdmin), para além das vulnerabilidades do MySQL tens
ADICIONALMENTE as vulnerabilidades do PHPMyAdmin, mais as do Apache,
mais as do PHP e de tudo o que tiveste de instalar para ter a porcaria do
PHPMyAdmin.

Além disso, tens um porto adicional exposto. Que é um buraco de segurança
ainda maior.

Eh pá, sinceramente...
[8b] [8b] [8b]

 

[Titanio]

Bom, mesmo antes desta conversa, pela análise que fiz e como já disse, dei preferência à instalação individual do MySQL, do PHP, do Apache, etc., e também do Workbench, isto porque dei preferência ao gestor do mesmo fabricante da base de dados.

Quando se começa do zero convém fazê-lo de forma estruturada e sem grandes flores.

Só para nos posicionarmos, eu sou um autodidata e nunca fiz uma hora de formação na área. Mas há que atribuir o devido mérito a um ou dois amigos, especialistas em Cobol e RPG que foram uma ajuda importantíssima nos meus primeiros passos. Curiosamente já dei formação do DOS, do Windows, de Word, Excel, do Lotus Notes, dBase, .... mas não, não sou expert e sim uma pessoa muito interessada e que faz estas brincadeiras por desporto, aproveitando uns cobres para investir a área. De novato também tenho pouco, já que ando nestas lides há tanto ou mais tempo que o Nuno, com a diferença de que não faço disto profissão, sendo apenas um hobby com alguma rentabilidade.

Convém é não nos zangarmos por causa de um simples software! Respeitemos as opiniões e discutámo-las de forma saudável, porque assim todos aprendemos sempre alguma coisa []

O Nuno falou aí para trás no Clipper e sim, programei muito em Clipper e ainda tenho aplicações comerciais a correr. Incrível não é? Numa altura destas correr aplicações feitas em Clipper parece impensável!

E instalei o MySQL e o PHP com a intenção de conhecer o PHP e, quiçá, desenvolver alguma coisa. Optei pelo PHP, não sei se bem ou mal, por se tratar de uma linguagem multiplataforma e da facilidade de gestão à distância, pela Web.

Estejam à vontade para corrigir alguma falha minha, sem stresses (e procurando evitar discussões desnecessárias).

E, já agora, aproveito para perguntar: será o PHP uma boa opção para me embrenhar nela?

 

[sylva]

Sou um autodidata e não percebo nem metade que voçês mas sei que a programação é o futuro num país quase falido quem não entrar nela à força é um analfabeto do futuro

 

[Nuno156]

(...)
já que ando nestas lides há tanto ou mais tempo que o Nuno, com a diferença de que não faço disto profissão, sendo apenas um hobby com alguma rentabilidade.
(...)
Estejam à vontade para corrigir alguma falha minha, sem stresses (e procurando evitar discussões desnecessárias).

E, já agora, aproveito para perguntar: será o PHP uma boa opção para me embrenhar nela?

25 anos profissionalmente.
Como hobby desde 1981.

As discussões desnecessárias são fruto de quando alguém insiste num erro.

Quanto ao PHP...
Nim.
Depende.
As tecnologias devem ser escolhidas em função do projecto que se pretende
implementar. Eu evitaria PHP para projectos complexos e críticos. Para coisas
simples o PHP serve.