ACE for sql injection filtering

I have an ACE module in a Cat6500, that is load balancing to some HTTP servers.
occasionally there are SQL injection attacks towards the http servers.
I know the ACE can filter based on http strings, but
If you can provide me with some basic templates on what to filter out and how to format the string
to stop SQL injection attacks, that would be of great help.
Cheers.

There are various signatures which are availbale for configuration for sql injection attacks. The signatures are some times application specific and it may not fit other application. Following links may help you
http://www.cisco.com/en/US/products/ps7314/products_white_paper0900aecd8068dcdb.shtml
http://www.cisco.com/en/US/products/ps7314/products_white_paper0900aecd80661ca6.shtml

Similar Messages

XML Validation using java for SQL Injection and script validation

I have an input coming from xml file.
I have to read that input and validate the input against sql injections and scripts.
I require help now how to read this xml data and validate against the above two options.
I am a java developer.
in this context what is marshelling?

http://www.ibm.com/developerworks/library/x-javaxmlvalidapi.html?ca=dgr-lnxw07Java-XML-Val
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/package-summary.html
The following code validates the xml against a xml schema
// define the type of schema - we use W3C:
String schemaLang = "http://www.w3.org/2001/XMLSchema";
SchemaFactory factory = SchemaFactory.newInstance(schemaLang);
Schema schema = factory.newSchema(new StreamSource("sample.xsd"));
Validator validator = schema.newValidator();
// at last perform validation:
validator.validate(new StreamSource("sample.xml"));Message was edited by:
haishai

Sql injection character fields

Is it true that with MSSQL in the background, character fields can't be used for sql injection?
A)   One source says that in MSSQL single quotes are escaped into double quotes.
B)   Another source says that " SQL injection (within ColdFusion apps) is really only an issue with non textual fields. If a text value is tampered with you'll end up with tampered text, but that text will all be part of the core string (within quotes) passed as a value, and will therefore not be executed as separate statements. Numbers, on the other hand, are not enclosed within quotes, and so extraneous text can be tampered "
Questions about A):   How does escaping 's with "s help, by making string literals in MSSQL not valid?
                                How could A) above be true when names like O'Mally are being stored with a single quote ?
Questions about B)    Does it mean code like DELETE * FROM atable would just be stored as a string and not execute ?
                                If so, is that accurate ?

To actually answer your question's.
A) A single quote in SQL is a comment. To store a single quote as DATA one has to escape it by doubling it. So to store O'Mally it would be passed as o''Mally.
The simple SQL injection attack is to end a number value with a random value, that is followed with a ; to end the SQL statment and then another statement can be run, this is then followed by a single quote to comment out any other SQL in the original statement. ColdFusion automatically escapes single quotes in text fields in most situations, so this is harder to do with text fields, but not impossible.

CS3/CS4 protecting against SQL Injection

Hi:
I was wondering if the newer versions of Dreamweaver like CS3/CS4 do a good enough job to protect against SQL Injection when using the built in Insert/Update/Delete behaviors or should I use Commands with Stored Procedures (MS SQL)?
Thanks!
Mitch

David , Günter - many thanks for your help !
In my ignorance I appear to have been misled by my website host who, in response to a related problem, informed me as follows:
"your website's scripting does appear to be highly vulnerable to SQL injection attack, this can be easily seen via the following example:
/s-sub_detail.php?cat_id=TEST
As you can see, arbitrary data entered as the cat_id variable of the shopping cart script is being passed unchecked to the SQL server, which is then returning a notice relevant to the data passed (in the above example case this is an "unknown column" error) - This effectively demonstrates that your shopping cart script performs no validation on variables used within the script and passes them directly to the SQL server, which means arbitrary commands can potentially be added as variable data for the SQL server to execute.
In order to correct this all variables and any other posted data used by the shopping cart script must be fully validated by the script itself before being passed to the SQL server so that SQL commands cannot be executed by simply manually entering these as a script variable".
Thanks to David I understand the issue with the need for data validation but the response above appears to indicate that they believe there is more to it.
David and Günter - I would welcome your response to the above and perhaps recommendations for SQL injection vulnerability testing.
Kind regards
J

ADF and SQL-Injection?

Hi
As I understand there is no any protection!!! Do view parameters work as parameters in JDBC prepared statement? I looked at examples and it looks they are just replaced with string as parameter value to make new string !!!
Andrius

Andrius,
to my knowledge only prepared statements provide you some level of safety and even herte I would recommend caution. The recommended approach for SQL Injection is to filter it either in a Servlet filter (which may be hard to do, but there is a library called mod_security by Ian Ristic that is open source and can be configured for additional security). In addition you can add custom code to the BC code that sets the parameters for the parameterized query to check for SQL injection. This can be done with Regular Expressions:
As an example:
Pattern p = Pattern.compile("(?i)\\bcreate|insert|delete|drop|update\\b");
Matcher m = p.matcher(username);
if (m.find())
// reject the request
Note that the example doesn't check for all possible patterns
Depending on your front end, additional checks can be provided. If e.g. in teh future you build applications with JSF, you could create a RegEx Validator to filter SQL injections.
Oracle ADF V2 comes with a declarative validator on the data binding level that support Regular Expressions defined on the attribute level. This I think should provide you the level of security you will expect.
Frank

Web and Database Security - SQL Inject info

Web and Database Security - SQL Injection.
Here is a whitepaper on The Dangers of Dynamic Content (SQL Injection)
http://www.issadvisor.com/viewtopic.php?t=125
SQL Injection. 3 parts. The first part discusses the basics of how to test
web applications for SQL injection vulnerabilities. The second part goes into
the specifics of how to manually identify and test for SQL injection
vulnerabilities. And the third part describes how to exploit SQL injection to
retrieve data from the database.
http://www.issadvisor.com/viewtopic.php?t=123
Understanding this critical security issue, helps web developers that leverage
database must design and make their applications more secure.
Hopefully these two links are informative and useful. Please pass them on.

An APEX page can certainly be configured to not require authentication (that's pretty standard for the login/ registration page). There is no need for an "Oracle public password." There are accounts in the Oracle database that APEX uses but that no human needs to know the password for. If that's what you mean by "Oracle public password" then, yes, you do. But that would be the case no matter what authentication and authorization scheme you use in APEX.
A static IP address for your web server is likely a good idea. It's possible to have DNS work with dynamic IP addresses but that's probably not what you want.
Justin

Preventing sql injection attack

string objConn9 = "Provider = MSDAORA;User ID=103109798;Password=password;Data Source=orabis;";
                              OleDbConnection myConnection9 = new OleDbConnection(objConn9);
                              string commandString9 = "INSERT INTO users(username,password)VALUES(:username,:password)";
                              OleDbCommand myCommand9 = new OleDbCommand(commandString9, myConnection9);
                              myCommand9.Parameters.Add(":username", txtUsername.Text);
                              myCommand9.Parameters.Add(":password", txtPassword.Text);
                              myConnection9.Open();
                              myCommand9.ExecuteNonQuery();
                              myConnection9.Close();
i'm using this code to try to remove the problem of
users entering a comma or an semi colon and throwing off my query, but its not working...
is there an easy way to insert text values into oracle 8i
that contain '; etc without throwing it off. I'm developing through c# and oracle 8i, the problem is most of the code examples are related to sql server and vb.net

I may be off here, but in this case you appear to be okay. The code snippet you include looks to me like it is using bind variables. If you are using bind variables you are not susceptible to sql injection attacks.
It is only when concatenating a string together to make a sql statement that injection attacks can occur.
See
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:668624442763#18067076079313
and search for injection.
Or just go to
http://asktom.oracle.com
and search for "sql injection bind variable" for lots of other references.

Dreamweaver CS3 and sql injection....

Any news if Dreamweaver CS3 will have the same "problems"
brought on by the
8.0.2 update to Dreamweaver 8?
Thanks!

Excellent...glad to hear it and I look forward to getting
CS3. I held off
on 8 because of the so called problems.
"Murray *ACE*" <[email protected]> wrote
in message
news:[email protected]...
> Yes, that's what I do. Honestly, I've not seen any
problems there.
>
> --
> Murray --- ICQ 71997575
> Adobe Community Expert
> (If you *MUST* email me, don't LAUGH when you do so!)
> ==================
>
http://www.dreamweavermx-templates.com
- Template Triage!
>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
> ==================
>
>
> "Pizza Good" <[email protected]> wrote in
message
> news:[email protected]...
>>I think it comes up more when you have a form and
pass the values to a
>>recordset which uses those values to query and filter
a recordset.
>>
>>
>> "Murray *ACE*"
<[email protected]> wrote in message
>> news:[email protected]...
>>>I am processing form input, which I believe is
where SQL injection comes
>>>in.
>>>
>>> --
>>> Murray --- ICQ 71997575
>>> Adobe Community Expert
>>> (If you *MUST* email me, don't LAUGH when you do
so!)
>>> ==================
>>>
http://www.dreamweavermx-templates.com
- Template Triage!
>>>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>>>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>>>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
>>> ==================
>>>
>>>
>>> "Pizza Good" <[email protected]> wrote
in message
>>> news:[email protected]...
>>>> That's good, or perhaps you are not building
the types of sites that
>>>> may encounter the so called problems?
>>>>
>>>>
>>>> "Murray *ACE*"
<[email protected]> wrote in message
>>>> news:[email protected]...
>>>>>I have to say that I've used 8.0.2 with
such things quite a bit and not
>>>>>encountered *any* of the posted problems.
>>>>>
>>>>> --
>>>>> Murray --- ICQ 71997575
>>>>> Adobe Community Expert
>>>>> (If you *MUST* email me, don't LAUGH
when you do so!)
>>>>> ==================
>>>>>
http://www.dreamweavermx-templates.com
- Template Triage!
>>>>>
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
>>>>>
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
>>>>>
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
>>>>> ==================
>>>>>
>>>>>
>>>>> "Paul Whitham AdobeCommunityExpert"
<[email protected]> wrote in
>>>>> message
news:[email protected]...
>>>>>> Using stored procedures is a good
safe guard against SQL injection
>>>>>> because you have to define your
parameter types, in much the same way
>>>>>> that the parameters in the 8.0.2
worked.
>>>>>>
>>>>>> Yes it did break a number of
extensions because the underlying code
>>>>>> was completely rewritten but it is
my understanding that most of
>>>>>> these were subsequently patched to
work with it.
>>>>>>
>>>>>> --
>>>>>> Paul Whitham
>>>>>> Certified Dreamweaver MX2004
Professional
>>>>>> Adobe Community Expert - Dreamweaver
>>>>>>
>>>>>> Valleybiz Internet Design
>>>>>> www.valleybiz.net
>>>>>>
>>>>>> "Pizza Good"
<[email protected]> wrote in message
>>>>>>
news:[email protected]...
>>>>>>>I think what he is referring to
is the sql injection "prevention"
>>>>>>>code that was introduced in the
8.0.2 update. I read a bunch of
>>>>>>>issues related to the way
recordsets were coded and that a page that
>>>>>>>was coded lets say in ASP using
8.0.1 that had used QueryString
>>>>>>>values that were passed into the
recodset for filtering/searching no
>>>>>>>longer worked. I also read that
8.0.2 "broke" a lot of extensions
>>>>>>>because of the fix.
>>>>>>>
>>>>>>> I am still using MX2004, but I'm
curious if the supposed problems
>>>>>>> that came up with 8.0.2 could be
totally avoided if a programmer
>>>>>>> used Stored Procedures?
>>>>>>>
>>>>>>> Hopefully that makes sense.
>>>>>>>
>>>>>>>
>>>>>>> "Paul Whitham
AdobeCommunityExpert" <[email protected]> wrote in
>>>>>>> message
news:[email protected]...
>>>>>>>> Most of the change that was
made to the recordset in 8.0.2 was to
>>>>>>>> eliminate SQL injections.
What specifically are you refering to as
>>>>>>>> an issue now
>>>>>>>>
>>>>>>>> --
>>>>>>>> Paul Whitham
>>>>>>>> Certified Dreamweaver MX2004
Professional
>>>>>>>> Adobe Community Expert -
Dreamweaver
>>>>>>>>
>>>>>>>> Valleybiz Internet Design
>>>>>>>> www.valleybiz.net
>>>>>>>>
>>>>>>>> "Brendon"
<[email protected]> wrote in message
>>>>>>>>
news:[email protected]...
>>>>>>>>> Those that are beta
testing it would know - if they were doing
>>>>>>>>> serverside/sql related.
It wouldn't be speculation at all - in
>>>>>>>>> fact it would be pretty
straight forward to test.
>>>>>>>>> I'd be very surprised if
they havn't fixed the issue - in fact I
>>>>>>>>> thought it was fixed in
the 8.0.2 update, but I could be wrong.
>>>>>>>>>
>>>>>>>>> Brendon
>>>>>>>>>
>>>>>>>>> "Deaf Web Designer"
<[email protected]> wrote in
>>>>>>>>> message
news:[email protected]...
>>>>>>>>>> DW CS3 is not here
as yet.
>>>>>>>>>>
>>>>>>>>>> Only time will tell
once you have DW CS3 installed on your
>>>>>>>>>> platform and find
>>>>>>>>>> out if that is the
case.
>>>>>>>>>>
>>>>>>>>>> At this point, it is
all speculation without knowing the fact of
>>>>>>>>>> the problem.
>>>>>>>>>> Try to be a bit more
patient until official release of product
>>>>>>>>>> sometime this
>>>>>>>>>> spring.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

SQL Injection concerns

I have been studying sql injection attacks and the
mysql_real_escape function.
I read the adobe technote about sql injection and it noted
that Dreamweaver 8.0 incorporates anti-sql injection code to
prevent attacks and it specifically refers to Add, Delete, and
Update; Filtered Recordsets, and Login User server behaviors. Can
anyone please confirm this to put my mind at ease?
The Search form and results page uses a filtered recordset,
so can I presume that it is guarded from attack?
Can you tell me of any areas that I need to add anti-sql
injection code myself?
Thank you so much for your help!

EviePhillips wrote:
> The code on this second page (the one where the form
posts to) ECHOs the form
> variables. Do I need to enter the
mysql_real_escape_string around each of the
> ECHOed posted form variables?
No, mysql_real_escape_string() is used only when inserting
user input
values into a database. You cannot use it without a database
connection.
However, you should pass the values to htmlentitities()
before
displaying them in your page. You can do this by accessing
the Format
menu in the Dynamic Text dialog box. After using the Bindings
panel to
insert the value, switch to the Server Behaviors panel, and
double-click
the Dynamic Text entry to open the dialog box.
> I am then going to use the ADD Record server behavior to
add the data to my
> database from this page, which based on your counsel is
fully protected from
> sql injection.
>
> You are very kind for sharing your knowledge!
> EP
>
David Powers, Adobe Community Expert
Author, "The Essential Guide to Dreamweaver CS4",
"PHP Solutions" & "PHP Object-Oriented Solutions"
http://foundationphp.com/

GeoRaptor 3.0 for SQL Developer 3.0 and 2.1 has now been released

Folks,
I am pleased to announce that, after 5 months of development and testing, a new release of GeoRaptor for SQL Developer 2.1 and 3.0 is now available.
GeoRaptor for SQL Developer 3 is available via the SQL Developer Update centre. GeoRaptor 3 for SQL Developer 2.1 is being made available
via a download fro the GeoRaptor website.
No release notes have been compiled as the principal developer (oops, that's me!) is currently busy doing real work for a change (another 3 weeks), earning a living
and keeping the wolves at bay. More extensive notes (with images) will be compiled when I get back. (Unless anyone is offering! See next.)
We are still looking for people to:
1. Provide translations of the English dialog menus etc.
2. Write more extensive user documentation. If you use a particular part of GeoRaptor a lot and think
you have found out all its functionality and quirks, contact us and offer to write a few pages of
documentation on it. (Open Office or Microsoft Word is fine.) Easiest way to do this is to simply
make screen captures and annotate with text.
3. Conduct beta testing.
Here are the things that are in the new release.
New functionality:
Overhaul of Validation Functionality.
1. User can specify own validation SELECT SQL as long as it returns three required columns. The SQL is thus totally editable.
2. Validation update code now allows user to associate a PL/SQL function with an error number which is applied in the UPDATE SQL.
3. UPDATE SQL can use WHERE clause of validation SELECT SQL (1) to update specific errors.
   NOTE: The generated UPDATE statement can be manually edited. It is NEVER run by GeoRaptor. To run any UPDATE, copy the statement
   to the clipboard and run in an appropriate SQL Worksheet session within SQL Developer.
4. Main validation table allows:
   a. Sorting (click on column header) and
   b. Filtering.
   c. Copying to Clipboard via right mouse click sub menu of:
      - Geometry's SDO_ELEM_INFO array constructor.
      - SDO_GEOMETRY constructor
      - Error + validation string.
   d. Access to Draw/Zoom functions which were previously buttons.
   e. Added a new right mouse click menu "Show Feature's Individual Errors" that gathers up all the errors
      it can process - along with the ring / element that is host to the error (if it can) - and displays
      them in the Attribute/Geometry tabs at the bottom of the Map Window (where "Identify" places its results).
      The power of this will be evident to all those who have wanted a way of stepping through errors in a geometry.
   f. Selected rows can now be deleted (select rows: press <DELETE> key or right mouse click>Delete).
   g. Table now has only one primary key column, and has a separate error column holding the actual error code.
   h. Right mouse click men added to table menu to display description of error in the new column (drawn from Oracle documentation)
   i. Optimisations added to improve performance for large error lists.
5. Functionality now has its own validation layer that is automatically added to the correct view.
   Access to layer properties via button on validation dialog or via normal right mouse click in view/layer tree.
Improved Rendering Options.
1. Linestring colour can now be random or drawn from column in database (as per Fill and Point colouring)
2. Marking of SDO_GEOMETRY objects overhauled.
   - Ability to mark or LABEL vertices/points of all SDO_GEOMETRY types with coordinate identifier and
     option {X,Y} location. Access is via Labelling tab in layer>properties. Thus, coordinate 25 of a linestring
     could be shown as: <25> or {x,y} or <25> {x,y}
   - There is a nice "stacked" option where the coordinate {x,y} can be written one line below the id.
   - For linestrings and polygons the <id> {x,y} label can be oriented to the angle between the vectors or
     edges that come in, and go out of, a vertex. Access is via "Orient" tick box in Labelling tab.
   - Uses Tools>Preferences>GeoRaptor>Visualisation>SDO_ORDINATE_ARRAY bracket around x,y string.
3. Start point of linestring/polygon and all other vertices can be marked with user selectable point marker
   rather than previously fixed markers.
4. Can now set a NULL point marker by selecting "None" for point marker style pulldown menu.
5. Positioning of the arrow for linestring/polygons has extra options:
   * NONE
   * START    - All segments of a line have the arrow positioned at the start
   * MIDDLE   - All segments of a line have the arrow positioning in the middle.
   * END      - All segments of a line have the arrow positioning in the END.
   * END_ONLY - Only the last segment has an arrow and at its end.
ScaleBar.
1. A new graphic ScaleBar option has been added for the map of each view.
   For geographic/geodetic SRIDs distances are currently shown in meters;
   For all SRIDs an attempt is made to "adapt" the scaleBar units depending
   on the zoom level. So, if you zoom right in you might get the distance shown
   as mm, and as you zoom out, cm/m/km as appropriate.
2. As the scaleBar is drawn, a 1:<DEMONINATOR> style MapScale value is written
   to the map's right most status bar element.
3. ScaleBar and MapScale can be turned off/on in View>Properties right mouse
   click menu.
Export Capabilities.
1. The ability to export a selection from a result set table (ie result of
   executing ad-hoc SQL SELECT statement to GML, KML, SHP/TAB (TAB file
   adds TAB file "wrapper" over SHP) has been added.
2. Ability to export table/view/materialised view to GML, KML, SHP/TAB also
   added. If no attributes are selected when exporting to a SHP/TAB file, GeoRaptor
   automatically adds a field that holds a unique row number.
3. When exporting to KML:
   * one can optionally export attributes.
   * Web sensitive characters < > & etc for KML export are replaced with > < & etc.
   * If a column in the SELECTION or table/view/Mview equals "name" then its value is
     written to the KML tag <name> and not to the list of associated attributes.
     - Similarly for "description" -> <description> AND "styleUrl" -> <styleUrl>
4. When exporting to GML one can optionally export attributes in FME or OGR "flavour".
5. Exporting Measured SDO_GEOMETRY objects to SHP not supported until missing functionality
   in GeoTools is corrected (working with GeoTools community to fix).
6. Writing PRJ and MapInfo CoordSys is done by pasting a string into appropriate export dialog box.
   Last value pasted is remembered between sessions which is useful for users who work with a single SRID.
7. Export directory is remembered between sessions in case a user uses a standard export directory.
8. Result sets containing MDSYS.SDO_POINT and/or MDSYS.VERTEX_TYPE can also be written to GML/KML/SHP/TAB.
   Example:
   SELECT a.geom.sdo_point as point
     FROM (SELECT sdo_geometry(2002,null,sdo_point_type(1,2,null),sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,1,2,2)) as geom
             FROM DUAL) a;
   SELECT mdsys.vertex_type(a.x,a.y,a.z,a.w,a.v5,a.v6,a.v7,a.v8,a.v9,a.v10,a.v11,a.id) as vertex
     FROM TABLE(mdsys.sdo_util.getVertices(mdsys.sdo_geometry(2002,null,null,sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,1,2,2)))) a;
9. A dialog appears at the end of each export which details (eg total) what was exported when the exported recordset/table contains more
   than on shape type. For example, if you export only points eg 2001/3001 from a table that also contains multipoints eg 2005/3005 then
   the number of points exported, and multipoints skipped will be displayed.
10. SHP/TAB export is "transactional". If you set the commit interval to 100 then only 100 records are held in memory before writing.
    However, this does not currently apply to the associated DBASE records.
11. SHP/TAB export supports dBase III, dBase III + Memo, dBase IV and dBase IV + Memo.
    Note: Memo allows text columns > 255 characters to be exported. Non-Memo formats do not and any varchar2 columns will be truncated
    to 255 chars. Some GIS packages support MEMO eg Manifold GIS, some do not.
12. Note. GeoRaptor does not ensure that the SRID of SDO_GEOMETRY data exported to KML is in the correct Google Projection.
    Please read the Oracle documentation on how to project your data is this is necessary. An example is:
    SELECT OBJECTID,
           CODIGO as name,
           NOME as description,
           MI_STYLE,
           SDO_CS.TRANSFORM(shape,'USE_SPHERICAL',4055) as shape
      FROM MUB.REGIONAL;
13. NOTE: The SHP exporter uses the Java Topology Suite (JTS) to convert from SDO_GEOMETRY to the ESRI Shape format. JTS does not handle
    circular curves in SDO_GEOMETRY objects you must "stroke" them using sdo_util.arc_densify(). See the Oracle documentation on how
    to use this.
Miscellaneous.
1. Selection View - Measurement has been modified so that the final result only shows those geometry
   types that were actually measured.
2. In Layer Properties the Miscellaneous tab has been removed because the only elements in it were the
   Geometry Output options which have now been replaced by the new GML/KML/etc export capabilities.
3. Shapefile import's user entered tablename now checked for Oracle naming convention compliance.
4. Identify based on SDO_NN has been removed from GeoRaptor given the myriad problems that it seems to create across versions
   and partitioned/non-partitioned tables. Instead SDO_WITHIN_DISTANCE is now used with the actual search distance (see circle
   in map display): everything within that distance is returned.
5. Displaying/Not displaying embedded sdo_point in line/polygon (Jamie Keene), is now controlled by
   a preference.
6. New View Menu options to switch all layers on/off
7. Tools/Preferences/GeoRaptor layout has been improved.
8. If Identify is called on a geometry a new right mouse click menu entry has been added called "Mark" which
   has two sub-menus called ID and ID(X,Y) that will add the labeling to the selected geometry independently of
   what the layer is set to being.
9. Two new methods for rendering an SDO_GEOMETRY object in a table or SQL recordset have been added: a) Show geometry as ICON
   and b) Show geometry as THUMBNAIL. When the latter is chosen, the actual geometry is shown in an image _inside_ the row/column cell it occupies.
   In addition, the existing textual methods for visualisation: WKT, KML, GML etc have been collected together with ICON and THUMBNAIL in a new
   right mouse click menu.
10. Tables/Views/MViews without spatial indexes can now be added to a Spatial View. To stop large tables from killing rendering, a new preference
    has been added "Table Count Limit" (default 1,000) which controls how many geometry records can be displayed. A table without a spatial
    index will have its layer name rendered in Italics and will write a warning message in red to the status bar for each redraw. Adding an index
    which the layer exists will be recognised by GeoRaptor during drawing and switch the layer across to normal rendering.
Some Bug Fixes.
* Error in manage metadata related to getting metadata across all schemas
* Bug with no display of rowid in Identify results fixed;
* Some fixes relating to where clause application in geometry validation.
* Fixes bug with scrollbars on view/layer tree not working.
* Problem with the spatial networks fixed. Actions for spatial networks can now only be done in the
schema of the current user, as it could happen that a user opens the tree for another schema that
has the same network as in the user's schema. Dropping a drops only the network of the current connected user.
* Recordset "find sdo_geometry cell" code has been modified so that it now appears only if a suitable geometry object is
in a recordset. Please note that there is a bug in SQL Developer (2.1 and 3.0) that causes SQL Developer to not
register a change in selection from a single cell to a whole row when one left clicks at the left-most "row number"
column that is not part of the SELECT statements user columns, as a short cut to selecting a whole row. It appears
that this is a SQL Developer bug so nothing can be done about it until it is fixed. To select a whole row, select all
cells in the row.
* Copy to clipboard of SDO_GEOMETRY with M and Z values forgot has extraneous "," at the end.
* Column based colouring of markers fixed
* Bunch of performance improvements.
* Plus (happily) others that I can't remember!If you find any bugs register a bug report at our website.
If you want to help with testing, contact us at our website.
My thanks for help in this release to:
1. John O'Toole
2. Holger Labe
3. Sandro Costa
4. Marco Giana
5. Luc van Linden
6. Pieter Minnaar
7. Warwick Wilson
8. Jody Garnett (GeoTools bug issues)
Finally, when at the Washington User Conference I explained the willingness of the GeoRaptor Team to work
for some sort of integration of our "product" with the new Spatial extension that has just been released in SQL
Developer 3.0. Nothing much has come of that initial contact and I hope more will come of it.
In the end, it is you, the real users who should and will decide the way forward. If you have ideas, wishes etc,
please contact the GeoRaptor team via our SourceForge website, or start a "wishlist" thread on this forum
expressing ideas for future functionality and integration opportunities.
regards
Simon
Edited by: sgreener on Jun 12, 2011 2:15 PM

Thank you for this.
I have been messing around with this last few days, and i really love the feature to pinpoint the validation errors on map.
I has always been so annoying to try pinpoint these errors using some other GIS software while doing your sql.
I have stumbled to few bugs:
1. In "Validate geometry column" dialog checking option "Use DimInfo" actually still uses value entered in tolerance text box.
I found this because in my language settings , is the decimal operators
2. In "Validate geometry column" dialog textboxs showing sql, doesn't always show everything from long lines of text (clipping text from right)
3. In "Validate geometry column" dialog the "Create Update SQL" has few bugs:
- if you have selected multiple rows from results and check the "Use Selected Geometries" the generated IN-clause in SQL with have same rowid (rowid for first selected result) for all entries
Also the other generated IN clause in WHERE-clause is missing separator if you select more than one corrective function
4. "Validate geometry column" dialog stays annoyingly top most when using "Create Update SQL" dialog

SQL Injection, replace single quote with two single quotes?

Is replacing a single quote with two single quotes adequate
for eliminating
SQL injection attacks? This article (
http://www.devguru.com/features/kb/kb100206.asp
) offers that advice, and it
enabled me to allow users to search name fields in the
database that contain
single quotes.
I was advised to use "Paramaterized SQL" in an earlier post,
but I can't
understand the concept behind that method, and whether it
applies to
queries, writes, or both.

Then you can use both stored procedures and prepared
statements.
Both provide better protection than simply replacing
apostrophes.
Prepared statements are simple:
Set myCommand = Server.CreateObject("ADODB.Command")
...snip...
myCommand.CommandText = "INSERT INTO Users([Name], [Email])
VALUES (?, ?)"
...snip...
myCommand.Parameters.Append
myCommand.CreateParameter("@Name",200,1,50,Name)
myCommand.Parameters.Append
myCommand.CreateParameter("@Email",200,1,50,Email)
myCommand.Execute ,,128 'the ,,128 sets execution flags that
tell ADO not to
look for rows to be returned. This saves the expense of
creating a
recordset object you don't need.
Stored procedures are executed in a similar manner. DW can
help you with a
stored procedure through the "Command (Stored Procedure)"
server behavior.
You can see a full example of a prepared statement by looking
at DW's
recordset code after you've created a recordset using version
8.02.
"Mike Z" <[email protected]> wrote in message
news:eo5idq$3qr$[email protected]..
>I should have repeated this, I am using VBScript in ASP,
with an Access DB.
>

SQL Injection on CallableStatement

I will try to post this all in one line, as the tags are not working today. I know that one should use PreparedStatement over Statement to obviate the thread of a SQL injection attack. Is CallableStatement vulnerable as well? For reference, this would be running against an Oracle RDBMS. Thanks!
- Saish

I guess there is no hard-and-fast rule.Well, I guess the hard and fast rule is "only use
bound variables". If you've got a sane database
design then that shouldn't cause you any problems.
Dave.I agree. I was approaching the issue mainly from a security perspective in locking down a legacy system against SQL injection attacks. Using Eclipse, I was able to zero-in on usages of Statement fairly easily. But the more I looked into CallableStatement, the more I realized that I woud have to inspect each invocation manually. (Just in case someone did not bind variables or built a dynamic SQL string).
- Saish

SQL Injection and variable substitutions

Hello helpful forum, I'm trying to understand what really goes on "behind" the scenes
with the variable substitutions in order to protect from sql injections.
I'm using apex 3.0.0.00.20
The trickiest component seems to be a Report of type "pl/sql returning sql", since
multiple dynamic sql interpretations are done there.
consider the following innocent looking disaster:
DECLARE
l_out VARCHAR2(2000);
BEGIN
l_out := 'select * from test_injection t where t.name like ''%' || :NAME || '%''';
RETURN l_out;
END;
if NAME is a single quote the report will return:
failed to parse SQL query: ORA-00911: invalid character
which hints to the fact that NAME is not escaped, and you are in fact able to access db functions
as in: '||lower('S')||'
I also tried to put there a function that runs in a autonomous transaction to log its calls, and
I see that it's called five times for each request.
consider now the similar solution (notice the two single quotes):
DECLARE
l_out VARCHAR2(2000);
BEGIN
l_out := 'select * from test_injection t where t.name like ''%'' || :NAME || ''%''';
RETURN l_out;
END;
with this second example nothing of the above is possible.
So my theory (please confirm it or refute it) is that there is a first variable substitution done
at the pl/sql level (and in the second case :NAME is just a string so nothing is substituted).
Then the dynamic sql is executed and it returns the following string:
select * from test_injection t where t.name like '%' || :NAME || '%'
now another substitution is done (at an "APEX" level) and then query is finally executed to return
the rows to the report.
The tricky point seems to be that the first substitution doesn't escape the variable (hence the error
with the single quote), while the second substitution does.
Please let me know if this makes sense and what are the proper guidelines to avoid sql injection with
the different kinds of reports and components (SQL, pl/sql returning sql, processes, ...)
Thanks

Giovanni,
You should build report regions like this using the second method so that all bind variables (colon followed by name) appear in the resultant varchar2 variable, l_out in your example, which will then be parsed as the report query. This addresses not only the SQL injection problem but the shared-pool friendliness problem.
Scott

Sql injection

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.
[http://www.securityfocus.com/infocus/1644]
how oracle prevent sql injections?

mango_boy wrote:
damorgan wrote:
And they do so using bind variables
http://www.morganslibrary.org/reference/bindvars.html
and DBMS_ASSERT
http://www.morganslibrary.org/reference/dbms_assert.html
do you have any suggestion for mysql users??Yes. Install Oracle.

Sql injection update signature

hi,
we are currently comparing cisco ips to tippingpoint, i have a cisco ips in front and tippingpoint in the back, so we are checking if cisco ips is missing on a lot of stuff , and currently it is missing on SQL injection attacks and cross scripting, which seems to be the weak point in cisco ips, its missing a lot on sql injection signatures, i mean why a simple update/set command does not have a signature ?

Thank you for your reply, do you know how to get in contact with the ips signature engineers at Cisco , i would like to share my comparaison with them as well as an attack that is passing all sql injection signature containing update but with u%pdate and the sql database is interpreting it as a normal update.

ACE for sql injection filtering

Similar Messages

Maybe you are looking for