hi guys!!!!
lets chat on india broadband forum.....
is SQL injection is solved for india broadband forum??
regards
hi guys!!!!
lets chat on india broadband forum.....
is SQL injection is solved for india broadband forum??
regards
No its not and we keep getting attacks every now and then. A back up is created every 6 hours and saved off site to deal with new attacks.
Do you have any suggestions on hardening the server?
So how do you find your e6300 processor? does it work well? isint it too slow for these days? there are so many better processors in the market and you sound like some one who is very fond of technology.
By the way using a paid security suit will do you a lot of good.
Last edited by Admin; 2nd October 2009 at 06:57 PM. Reason: Automerged Doublepost
whats database you use??if you use ORACLE 10g or 11gR2 the safest option is DBMS_ASSERT and BIND variable.......
So you joined TSF........cool???
now give me my consultancy fees.........
LOL............
HTH
i will search for that.....mysql is lightweight db....you may convert to oracle 10g or DB2 9.5 to ensure high availability and reliability with security....although its a bit costly.but Db2 and oracle both response to php.
personally i don't like mysql.anyway you / your team can search for parallel options in mysql.this days a class 5 boys can hack a site with sql injection so how it is solved in mysql you can search for that....
HTH
http://www.securityfocus.com/infocus/1644
What is SQL Injection?
SQL Injection is a way to attack the data in a database through a firewall protecting it. It is a method by which the parameters of a Web-based application are modified in order to change the SQL statements that are passed to a database to return data. For example, by adding a single quote (‘) to the parameters, it is possible to cause a second query to be executed with the first.
An attack against a database using SQL Injection could be motivated by two primary objectives:
1. To steal data from a database from which the data should not normally be available, or to obtain system configuration data that would allow an attack profile to be built. One example of the latter would be obtaining all of the database password hashes so that passwords can be brute-forced.
2. To gain access to an organisation’s host computers via the machine hosting the database. This can be done using package procedures and 3GL language extensions that allow O/S access.
There are many ways to use this technique on an Oracle system. This depends upon the language used or the API. The following are some languages, APIs and tools that can access an Oracle database and be part of a Web-based application.
* JSP
* ASP
* XML, XSL and XSQL
* Javascript
* VB, MFC, and other ODBC-based tools and APIs
* Portal, the older WebDB, and other Oracle Web-based applications and API’s
* Reports, discoverer, Oracle Applications
* 3- and 4GL-based languages such as C, OCI, Pro*C, and COBOL
* Perl and CGI scripts that access Oracle databases
* many more.
Any of the above applications, tools, and products could be used as a base from which to SQL inject an Oracle database. A few simple preconditions need to be in place first though. First and foremost amongst these is that dynamic SQL must be used in the application, tool, or product, otherwise SQL Injection is not possible.
The final important point not usually mentioned in discussions about SQL injection against any database including Oracle is that SQL injection is not just a Web-based problem. As is implied in the preceding paragraph, any application that allows a user to enter data that may eventually end up being executed as a piece of dynamic SQL can potentially be SQL injected. Of course, Web-based applications present the greatest risk, as anyone with a browser and an Internet connection can potentially access data they should not.
While second article of this series will include a much more in-depth discussion of how to protect against SQL injection attacks, there are a couple of brief notes that should be mentioned in this introductory section. Data held in Oracle databases should be protected from employees and others who have network access to applications that maintain that data. Those employees could be malicious or may simply want to read data they are not authorized to read. Readers should keep in mind that most threats to data held within databases come from authorized users.
Protecting against SQL Injection on Oracle-based systems is simple in principle and includes two basic stages. These are:
1. Audit the application code and change or remove the problems that allow injection to take place. (These problems will be discussed at greater length in the second part of this series.)
2. Enforce the principle of least privilege at the database level so that even if someone is able to SQL inject an application to steal data, they cannot see anymore data than the designer intended through any normal application interface.
The “Protection” section, which will be included in the second part of this series, will discuss details of how to apply some of these ideas specifically to Oracle-based applications.
i am planning for EXADATA Storage and a SERVER with 2 CPU
it will rock then...........
Last edited by csayantan; 2nd October 2009 at 09:18 PM. Reason: Automerged Doublepost