Log Sanitizer

Statement

Goal

As a SecOps engineer, you must ensure that sensitive data never leaks into application logs.

For the purposes of this task, tokens are defined as being bounded by non-alphanumeric characters or the beginning or end of the line.

Inspect a stream of server log lines and sanitize all occurrences of the following two patterns, subject to the overlapping rule:

1. Credit card numbers
Exactly four consecutive tokens, each consisting of exactly 4 digits and joined by -, form a credit card number and should be replaced with [CARD_REDACTED].

2. API token
A token token (case-sensitive), immediately followed by = and another token (the value) consisting of one or more alphanumeric characters, forms an API token. Redact the value token only, replacing it with [TOKEN_REDACTED].

Overlapping rule
Overlapping occurrences of a single pattern should not be considered to fit the pattern and should remain unchanged. For example, this applies to:
• Five or more consecutive tokens, each consisting of exactly 4 digits and joined by -.
• token= appears consecutively two or more times.

If token= is immediately followed by a token consisting of exactly 4 digits, treat that 4-digit token as the API-token value. This takes precedence over any credit-card matching that might otherwise involve that token. Continue processing the remaining text after redacting that token.

All other log characters must remain untouched.

Input

Line 1: An integer N for the number of log lines.
Next N lines: A string line representing a raw log entry.

Output

N lines: The sanitized log entries.

Constraints

1 ≤ N ≤ 10
line contains between 1 and 100 printable ASCII characters.

Example

Input

4
[SYSTEM] Server running on port 8080 with 0 errors.
[TRANSFER] Moved funds from 8291-3849-1029-4820 to 5731-4921-5829-1039 confirmed.
192.168.1.1 - GET /auth?token=abC123XyZ HTTP/1.1
2023-10-01 12:00:00 INFO: Session initiated, token=validToken123 login success

Output

[SYSTEM] Server running on port 8080 with 0 errors.
[TRANSFER] Moved funds from [CARD_REDACTED] to [CARD_REDACTED] confirmed.
192.168.1.1 - GET /auth?token=[TOKEN_REDACTED] HTTP/1.1
2023-10-01 12:00:00 INFO: Session initiated, token=[TOKEN_REDACTED] login success

Rate this contribution

Make the contribution public (lvl 20+)

Comments

20 Comments

TBali Unnamed CodinGamer

6 days ago

✅ Approved the contribution. Comment: First I overcomplicated it, but the solution is actually simpler then I expected. Still, a careful consideration of all the rules is needed.

CriusMaximus Unnamed CodinGamer

19 days ago

✅ Approved the contribution. Comment: I like this contribution !

5DN1L Unnamed CodinGamer

19 days ago

Have you solved both puzzles you just approved?

RunninglVlan Unnamed CodinGamer

23 days ago

✅ Approved the contribution. Comment: Good puzzle, although not as easy as "You have been Hacked!" The only comment is about stub: - "line:string" feels like debug, maybe change it to "sanitized line" instead

Eng.Adnane Unnamed CodinGamer

21 days ago

Thanks a lot for the review and approval! I've updated the stub to "sanitized line" as suggested.

5DN1L Unnamed CodinGamer

about 1 month ago

Please switch the puzzle to WIP as there are significant issues that should be addressed first. (Consider switching your other puzzle to WIP too; I'll review it later today.) Goal * There are several issues with the current statement: • "Parameter" is undefined. • "Secret" is undefined in the phrase "secret value". How should a solver determine whether a value is secret? • The token-boundary constraint is unclear in how it applies to the rules. Moreover, the beginning-of-line boundary isn't included. • The token-boundary definition is more than an input constraint: it is part of the matching rules and is necessary for correctly parsing and transforming the raw log entries. • Including the pattern [a-zA-Z0-9]+ gives away a hint, as it can potentially be used directly in the solution, and, in fact, it's used in your solution. • The statement is silent on overlapping occurrences. For example, - What should happen when there are 5 or more consecutive 4-digit tokens joined by "-", e.g. "1234-2234-3234-4234-5234"? Should the first 4 tokens be redacted, or should the entire sequence be regarded as not matching the credit-card pattern? - In particular, your code interprets 8 consecutive 4-digit tokens jointed by hyphens as two consecutive credit-card numbers and redacts them separately. I don't think that is necessarily the intended interpretation; such a sequence could, for example, represent a recovery code. - Similarly, how should "token=token=123" be handled? Your code currently redacts both the second "token" and 123. * In view of these issues, consider dropping the term "parameter", moving the token-boundary constraint to the Goal section, and rewriting as follows. ----- <<Tokens>> are bounded by non-alphanumeric characters or the beginning or end of the line. Inspect a stream of server log lines and sanitize all occurrences of the following two patterns, subject to the overlapping rule. 1. <<Credit card numbers>> Exactly four consecutive tokens, each consisting of exactly 4 digits and joined by {{-}}, form a credit card number and should be replaced with {{[CARD_REDACTED]}} 2. <<API token>> A token {{token}}, immediately followed by {{=}} and another token (the <<value>>) consisting of one or more alphanumeric characters, forms an API token. Redact the value token only, replacing it with {{[TOKEN_REDACTED]}}. <<Overlapping rule>> Overlapping occurrences of a single pattern should not be considered to fit the pattern and should remain unchanged. For example, this applies to: • Eight consecutive tokens, each consisting of exactly 4 digits and joined by {{-}}. • {{token=}} appears consecutively two or more times. ----- (character limit reached)

5DN1L Unnamed CodinGamer

about 1 month ago

(continued) * Note that this rewritten specification does *not* match your code's behaviour, but I believe it better reflects the intended behaviour. An example is the situation of 8 consecutive 4-digit tokens all joined by a hyphen as mentioned earlier. * Note also that the rewritten version (*unlike* your current code) treats any non-alphanumeric character immediately preceding "token" as a token boundary. Thus, "php?my_token=abc" would contain a "token=abc" API token. * The rewritten version (*like* your current code) treats any non-alphanumeric character immediately following an API value token as a token boundary. Thus, "php?token=abc_my" would contain a "token=abc" API token, and "_my" isn't part of it. * The statement should also clarify how to handle the situation when "token=" is immediately followed by a credit card number. Input * Please add the variable name [[line]] after "A string". Output * Please remove "with all sensitive card numbers and tokens redacted" as it suggests a scope wider than intended. Constraints * Please change 50 to 10 as [[N]] never exceeds 10. * Please change the second constraint to: [[line]] contains between 1 and 100 printable ASCII characters. * Also note that 250 has been replaced by 100 because no raw log entry is longer than 100 characters. * Please remove the third constraint. This should be moved to the Goal section, as explained above. Stub generator * Please change 250 to 100. Tags * Please use existing tags and replace "regular-expressions" with "Regular expressions". * Please also remove the "security" tag. Cases * Currently "token=" followed by a token at the end of a raw log entry appears in Validators 1 and 2 but not in any tests. Please modify Test 1 and/or Test 2 to include the same scenario. * Please add new pairs of cases covering scenarios not currently tested: • A credit card number at the beginning of a raw log entry • 3 or fewer groups of 4-digit tokens joined by a hyphen • 5 or more groups of 4-digit tokens joined by a hyphen • An otherwise valid credit card number immediately preceded by one or more letters • An otherwise valid credit card number immediately preceded by one or more digits • An otherwise valid credit card number immediately followed by one or more letters • An otherwise valid credit card number immediately followed by one or more digits • An otherwise valid credit card number uses multiple hyphens instead of a single hyphen • "token=" appearing consecutively • "token=" with variations in letter case • "token:" instead of "token=" • a raw log entry ending with "token=" with nothing following • "token=" followed by a credit card number • "token=" followed by one or more non-alphanumeric non-space characters • "token=" preceded by one or more non-alphanumeric non-space characters Thanks.

CriusMaximus Unnamed CodinGamer

about 1 month ago

*Difficulty Please change Easy to Nromal Thanks

5DN1L Unnamed CodinGamer

about 1 month ago

It's probably closer to Easy than Medium (there’s no Normal or Nromal difficulty). Also note that regex isn't really needed to solve the puzzle. There are a few issues with the task description and case coverage, though. I'm going to finish my review today.

ABOUT US CAREERS PRIVACY FAQ BLOG

The #1 tech hiring platform

SCREENING INTERVIEWING