QuickFIX/J

if set "\001" in the StringField, it cause lots of problems

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Default Default
  • Resolution: Unresolved
  • Affects Version/s: 1.2.1
  • Fix Version/s: Future Releases
  • Component/s: Engine
  • Labels:
    None

Description

If "\001" is set in the string field by users, it can't be validated before sending. The field is considered as user expected. But it could be validated when received. There are three cases:

(1)Error incorrect format when Agent receives.
e.g. newOrderSingle.set(new Symbol("\001WAKEN"));
8=FIX.4.4_9=142_35=D_34=346_49=ICBC_50=operator001_52=20071128-03:03:37.140_56=XXX_212=346_11=123_38=1_40=2_44=1_54=1_55=_WAKEN_60=20071128-11:03:37.125_10=XXX_
Agent: [ERROR] quickfix.mina.acceptor.AcceptorIoHandler - Invalid message: bad tag format: For input string: "WAKEN_60"

e.g. newOrderSingle.set(new Symbol("WAK\001EN"));
8=FIX.4.4_9=142_35=D_34=329_49=ICBC_50=operator001_52=20071128-
03:00:50.875_56=XXX_212=329_11=123_38=1_40=2_44=1_54=1_55=WAK_EN_60=20071128-11:00:50.875_10=XXX_
Agent: [ERROR] quickfix.mina.acceptor.AcceptorIoHandler - Invalid message: bad tag format: For input string: "EN_60"

e.g. newOrderSingle.set(new Symbol("WAKEN\001"));
8=iMIX.1.0_9=142_35=D_34=365_49=ICBC_50=operator001_52=20071128-
03:06:13.671_56=XXX_212=365_11=123_38=1_40=2_44=1_54=1_55=WAKEN__60=20071128-11:06:13.671_10=XXX_
Agent: [ERROR] quickfix.mina.acceptor.AcceptorIoHandler - Invalid message: bad tag format: For input string: "_60"

e.g. newOrderSingle.set(new Symbol("WAK\001=EN"));
8=iMIX.1.0_9=143_35=D_34=312_49=ICBC_50=operator001_52=20071128-
02:56:44.578_56=XXX_212=312_11=123_38=1_40=2_44=1_54=1_55=WAK_=EN_60=20071128-
10:56:44.562_10=XXX_
Agent:[ERROR] quickfix.mina.acceptor.AcceptorIoHandler - Invalid message: bad tag format: For input string: ""


(2)The message is rejected as expected.

e.g. newOrderSingle.set(new Symbol("WAK\001123=EN"));
8=iMIX.1.0_9=146_35=D_34=269_49=ICBC_50=operator001_52=20071128-
02:50:38.406_56=XXX_212=269_11=123_38=1_40=2_44=1_54=1_55=WAK_123=EN_60=20071128-
10:50:38.406_10=XXX_
Incorrect data format for value

e.g. newOrderSingle.set(new Symbol("\001123=EN"));
8=iMIX.1.0_9=143_35=D_34=248_49=ICBC_50=operator001_52=20071128-
02:49:02.406_56=XXX_212=248_11=123_38=1_40=2_44=1_54=1_55=_123=EN_60=20071128-
10:49:02.406_10=XXX_
Tag specified without a value

e.g. newOrderSingle.set(new Symbol("WAKEN\001123="));
8=iMIX.1.0_9=146_35=D_34=383_49=ICBC_50=operator001_52=20071128-
03:12:25.546_56=XXX_212=383_11=123_38=1_40=2_44=1_54=1_55=WAKEN_123=_60=20071128-
11:12:25.531_10=XXX_
Tag specified without a value

(3)The message is received successfully, but it is wrong. The result is critical. It will be used to attack the Server. This mustn't absolutely happen.
e.g. newOrderSingle.set(new Symbol("WAKEN\00110048=2"));
8=iMIX.1.0_9=149_35=D_34=449_49=ICBC_50=operator001_52=20071128-
03:21:47.031_56=XXX_212=449_11=123_38=1_40=2_44=1_54=1_55=WAKEN_10048=2_60=20071128-
11:21:47.015_10=XXX_

Solution 1
Encode the StringField at the Client, and decode at the Server. The encode and decode can be implemented in class StringField.
Fault:
In the FieldType "DATA", "\001" is permited. Its length is defined by the former field rather than by the position of "\001". So it is not affected by "\001". When encoded, its length will be changed. So the former field's value must be modified. To avoid this, a new class must be added instead of StringField. Make all
the "DATA" type extend StringField.

Solution 2
In the FIX protocol, the String field is not permit to be set as '\001'. So we can throw Exception directly or replace '\001' with ' ' in the StringField.
This can be implemented in class stringField. When construct a StringField except DATA fieldType, if find "\001", throw Exception directly or replace '\001' with ' '.
I think the solution 2 is better. The concisest method is to judge the DataField by tags. Now there are at least 3 pairs of DataField: 93/89, 95/96, 354/355.
Hard code is written:
if(field == 89||field == 96||field == 355)

Activity

Hide
Steve Bate added a comment - 08/Jan/08 11:51 PM

If I understand your concern correctly, this is more of a FIX protocol issue than a QuickFIX/J issue.On the QFJ side, we can validate
that a value of a String field doesn't contain a "\001". However, this doesn't stop the possibility of "server attacks". From the perspective
of the receiving engine, a "\001" is a field delimeter and the message will be parsed accordingly. Even if we validate the StringFields, your
counterparty can send whatever FIX message string they want with whatever fields they want so you must validate those anyway in your application
code.

Show
Steve Bate added a comment - 08/Jan/08 11:51 PM If I understand your concern correctly, this is more of a FIX protocol issue than a QuickFIX/J issue.On the QFJ side, we can validate that a value of a String field doesn't contain a "\001". However, this doesn't stop the possibility of "server attacks". From the perspective of the receiving engine, a "\001" is a field delimeter and the message will be parsed accordingly. Even if we validate the StringFields, your counterparty can send whatever FIX message string they want with whatever fields they want so you must validate those anyway in your application code.
Hide
Steve Bate added a comment - 11/Jan/08 12:22 AM

This is more involved than I thought it would be. The data fields are based on StringField so I need to think more about to provide validation for String versus data fields.

Show
Steve Bate added a comment - 11/Jan/08 12:22 AM This is more involved than I thought it would be. The data fields are based on StringField so I need to think more about to provide validation for String versus data fields.

People

  • Assignee:
    Unassigned
    Reporter:
    CaiQi
Vote (0)
Watch (0)

Dates

  • Created:
    24/Dec/07 11:53 AM
    Updated:
    12/Jan/08 2:33 PM