vanderaj
New member
Hi there,
I've been struggling to get DA to create a correct SPF record for about 2 years now. I've tried everything, including ... something which we use in the web application security field - I urlencoded the string hoping that would work.
Well, it sucks to be me right now. I can't delete this string. The value in the HTML input is now completely bogus, and I can't delete the bad SPF record.
What I have is:
The problem is that since DA creates its HTML in a non-XHTML compliant way, with no quotes and strangely encodes them (it seems to be using HTML entities for all non-ASCII characters, which should be nice and safe. Except now, the value string contains HTML entities, and DA fails miserably to delete that line.
The way it should look is:
Browsers will only submit this via POST when they have been checked:
txtrecs0=1
There's no reason to send ANY value other than a unique integer like 1 ... 2.. 3 ... 4. The value is totally irrelevant and using user supplied data is literally begging to be attacked. If DA is trusting this data in any way, it may create a direct object reference attack all the way through to XSS or SQL injection attacks, depending on how DA interprets this data. At the moment, all it is doing is giving me a DoS for e-mail.
I'd suggest moving to an indirect object reference map instead of user-supplied data. It's faster to validate (it'll be an integer), it's faster to check for attacks (if you send out 1..10 as values, and get 'z or 12, then you know you've been attacked), and it'll work no matter what sort of hairbrained rubbish I enter for the DNS record.
Lastly, can DA be updated to include the ability to accept a string for the SPF record and honor it? At the moment, any TXT record is sent out like this:
"v=spf1" "a" "mx" "~all"
which fails with EPERM with ALL the SPF record testers, and thus about 30-40% of the mail servers on the planet reject mail from my domain (before I stuffed up my own zone).
Can this be fixed? How do I delete this entry? I'm running 1.31 on FreeBSD 5.3. I do not have root access and have no idea who does.
thanks,
Andrew
I've been struggling to get DA to create a correct SPF record for about 2 years now. I've tried everything, including ... something which we use in the web application security field - I urlencoded the string hoping that would work.
Well, it sucks to be me right now. I can't delete this string. The value in the HTML input is now completely bogus, and I can't delete the bad SPF record.
What I have is:
Code:
<input type=checkbox name=txtrecs0 value="name=aussieveedubbers.com.&value==spf1%20a%20mx%20a:mail.aussieveedubbers.com%20~all">
The problem is that since DA creates its HTML in a non-XHTML compliant way, with no quotes and strangely encodes them (it seems to be using HTML entities for all non-ASCII characters, which should be nice and safe. Except now, the value string contains HTML entities, and DA fails miserably to delete that line.
The way it should look is:
Code:
<input type="checkbox" name="txtrecs0" value="1" />
Browsers will only submit this via POST when they have been checked:
txtrecs0=1
There's no reason to send ANY value other than a unique integer like 1 ... 2.. 3 ... 4. The value is totally irrelevant and using user supplied data is literally begging to be attacked. If DA is trusting this data in any way, it may create a direct object reference attack all the way through to XSS or SQL injection attacks, depending on how DA interprets this data. At the moment, all it is doing is giving me a DoS for e-mail.
I'd suggest moving to an indirect object reference map instead of user-supplied data. It's faster to validate (it'll be an integer), it's faster to check for attacks (if you send out 1..10 as values, and get 'z or 12, then you know you've been attacked), and it'll work no matter what sort of hairbrained rubbish I enter for the DNS record.
Lastly, can DA be updated to include the ability to accept a string for the SPF record and honor it? At the moment, any TXT record is sent out like this:
"v=spf1" "a" "mx" "~all"
which fails with EPERM with ALL the SPF record testers, and thus about 30-40% of the mail servers on the planet reject mail from my domain (before I stuffed up my own zone).
Can this be fixed? How do I delete this entry? I'm running 1.31 on FreeBSD 5.3. I do not have root access and have no idea who does.
thanks,
Andrew