5 ms·
OWASP Cheat Sheet Series
- logn 13y agoOn their Input Validation cheat sheet (https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet) they recommend this as an example zip-code validation: ^\d{5}(-\d{4})?$ Depending on the language and regex interpreter options, this isn't as strict as it could be since it might accept unicode numbers. For the paranoid, this would be better: ^[0-9]{5}(-[0-9]{4})?$ Edit: And security issues aside, there's really no need for a capturing group on the last four digits, thus it could be: ^[0-9]{5}(?:-[0-9]{4})?$
- mweibel 13y agoHow about chars in zip codes (afaik GB has chars in zip codes)? Input validation is usually a UX fail because there will be for sure one thing you miss (traditional example: email address validation). Zip codes I'd rather don't check at all or check against a list of valid zip codes if really necessary.
- henrik_w 13y agoAs do Canadian ZIP-codes.
- jasonlotito 13y agoWell, that's the thing, Canada doesn't have ZIP codes. ZIP codes are purely an American system. Canada has postal codes, and you can easily verify the format of them, as well as the location of Canadian postal codes. So if you know the person is in Canada, you simply check against a different set of rules.
- rmc 13y ago(afaik GB has chars in zip codes) Yes the UK has letters in postcodes.
- jwdunne 13y agoAnd the regex to validate this is a monster, even noting that this still allows bad input: (GIR 0AA)|((([A-Z-[QVX]][0-9][0-9]?)|(([A-Z-[QVX]][A-Z-[IJZ]][0-9][0-9]?)|(([A-Z-[QVX]][0-9][A-HJKSTUW])|([A-Z-[QVX]][A-Z-[IJZ]][0-9][ABEHMNPRVWXY])))) [0-9][A-Z-[CIKMOV]]{2}) http://stackoverflow.com/questions/164979/uk-postcode-regex-comprehensive http://stackoverflow.com/questions/164979/uk-postcode-regex-...
- rmc 13y agoThe UK Government (after OSM took off) started to open source and release more data. You can download[1] the database of most of the UK postcodes[2] and their latitude & longitude. So if you want to really verify a GB postcode, you can just check it against the list [1] It's called 'Code Point Open' and you can 'order' it (for free) here http://www.ordnancesurvey.co.uk/business-and-government/products/opendata-products.html http://www.ordnancesurvey.co.uk/business-and-government/prod... [2] It's most of UK. It doesn't include Northern Ireland
- logn 13y ago> Input validation is usually a UX fail I agree in general. I think it was just a contrived example though in interest of discussing security/validation. Their example was in context of US users (and US zip-codes don't deviate from the pattern, but yes you could go one step further and reference the zip-code against the state and address using an API). Also, specifically on regex, I'd imagine \d is being used in places where validation against unicode would be buggy (whether in form validation or elsewhere). I think Java and JavaScript default to ASCII only though.
- jasonlotito 13y agoZIP codes are an American thing. ZIP codes are a specific system of postal codes. If you are talking about ZIP codes, it's American. If you are validating an American address, you'd want to validate using something that validates a ZIP code. If you get a Canadian address, you'd want to validate against that (which also happens to make it simple to validate against the province as well). And yes, if you shouldn't using the term ZIP codes and postal codes interchangeably and treating them the same way in your code.
- mweibel 13y agoInteresting. I'm swiss and usually our postal codes are translated to zip code. Would postal code be the generic translation then?
- ctz 13y agoEvery time I read something from OWASP, it has a bunch of glaring deficiencies, and appears to be an uneditable wiki. This time around: Authentication_Cheat_Sheet: password rules which only apply to US-ASCII. That means people with non-US keyboards may not even be able to set a password which meet the rules (eg. Θ and ẞ are upper case, but does not count as upper case in their suggested rules). Password_Storage_Cheat_Sheet: misses the critical step of unicode canonicalisation and encoding before feeding the password into the slow one-way function (which invariably take an octet string, not textual strings). If you fail to do this, your system will spuriously reject correct passwords if the user logs in via different devices or input methods. Password_Storage_Cheat_Sheet: '32-bit or 64b' length salt is certainly too short to be called cryptographically strong. Particularly, a 32-bit salt is not enough to avoid leaking password equality with good probability between users once you get past the birthday bound. Password_Storage_Cheat_Sheet: implies that the caller is responsible for prepending the salt to the credential before inputting it into the slow one-way function. That's not how PBKDF2, scrypt or bcrypt work.
- hueving 13y agoYour assertion about the salt is wrong. That's not what a salt is designed to prevent. A salt is to prevent pregenerated tables from being meaningful, therefore 32-64bit is plenty. 'good probability' is a little dramatic too. The birthday paradox would only apply if every user had the same password to begin with. With 32 bits, you would need about 77000 users with the exact same password to get to 50% probability of two having the same salt/hash. 2000 users with the same password is 0.1% probability of two being the same. If you are concerned about equalities because you have thousands of users with the same password, input the username into the hash generation function as well. Don't waste space with needlessly large salts.
- ctz 13y agoLet's consider Adobe, since we have actual data. Of 130,324,429 users, we know 1,911,938 chose the password '123456'. Consider just that population of users. Assume a 64-bit salt was chosen uniformly at random for each user. The probability that this cryptosystem is catastrophically broken (i.e. leaks password equality between users in just this population) is about 2^-23. That's not good -- usually cryptosystems are designed to have a probability of failure between 2^-80 and 2^-256. Now multiply that up for each population of users choosing the same password, and you're in trouble. Adding in other user-unique data is definitely a good idea!
- davedx 13y agohttps://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet https://www.owasp.org/index.php/Web_Service_Security_Cheat_S... - ugh, "containers", SOAP and XML. Was hoping for something more general.
- deleted 13y ago[deleted]
- Fasebook 13y agoor "How to make sure only the NSA can circumvent your security"
- wglb 13y agoOne of the better examples of an OWASP cheat sheet is Rsnake's XSS: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She....
- tharri 13y agoDoes the fact that this site has "index.php" in all its URLs bother anyone else?
- ADFASFGADA 13y agoNope not really. Probably only tards who can't seem to see that most of the successful web runs on PHP, not on their Brogrammer flavour-of-the-week language or framework.
- e1ven 13y agoI tend to be rather language agnostic, but URLs should generally be a descriptor of the content, and leak as few technological details as possible. In general, having the URL include a specific implementation quirk, such as index.php makes it more difficult to have URLs that are stable years into the future, after you may have changed technology stacks.