The DMZ - 2019-12-05

« first day (3276 days earlier) ← previous day next day → last day (1596 days later) »

7:07 AM

I wish you all a good morning, my lads and ladders!

70

A: Keep password in macro?

This is a bad idea. As user mentioned in a comment, anyone with physical access can just press the assigned macro key and the password will be revealed. You also have a high chance of accidentally pressing the macro key, thus typing in your password in places where you didn't mean to. The macr...

^- Who would have thought something as simple as "You should use a password manager" would be that controversial.

8:06 AM

It's fascinating how many people believe that sudo cat fileA > fileB causes fileB to be written with root privileges. Even my boss assumed so, and he knows a lot more about stuff than me.

6 hours later…

1:55 PM

@MechMK1 I wouldn't actually worry too much about physical attackers for a home machine, but this is reason enough:

"You also have a high chance of accidentally pressing the macro key, thus typing in your password in places where you didn't mean to."

@ConorMancone This actually happens to me all the time.

I press Ctrl-V in Keepass to put my password in and suddenly it gets written into an e-mail :D

I actually had a similar problem. My monitor turns off after a few minutes of use, and my computer locks similarly. It takes a moment for the monitor to turn back on and it takes more time to turn on than it takes me to type in my password. As a result if my screen is blank I'll just type in my password and hit enter, and then by the time the monitor turns the computer will be unlocked

Until you realize your PC was not locked and now you typed your password into the DMZ :D

:) exactly

Normally I lock my computer when I step away but sometimes I forget, and it turns out that the "turn off monitor" setting is shorter than the "lock screen". So there was once where I returned to my computer, typed in my password, and sent my computer password to my companies general slack channel

Delete!

Not sure if slack deletes forever, but since I only use that password on my work computer, I decided not to worry about it (I work remotely anyway)

It'sFuckingMondayAgainAndTheCoffeeStillTastesLikeFuckingShit

2

2:00 PM

@MechMK1 And if you're using someone like Gmail it automatically saves it as a draft that can never, ever, ever be deleted from their servers. And then their smart typing algorithms later suggest it to you when filling out future emails...

@ConorMancone That sounds neat :D

lol, I want to star that so bad but without context it would probably just get you in trouble

Do it!

Chat ban in 5, 4, 3,... (j/k, I'm sure it'll be fine)

:D

2:17 PM

Is this all correct?

1

A: URL parameter manipulation and injection

tl/dr: Whether or not you have a reflected XSS vulnerability depends on the exact method you use to append the data. Therefore you should specifically check your chosen method to make sure it is safe. Modern javascript frameworks typically take care of these things automatically for yo...

Let me double check

It's been a while since I've used jQuery, so I'm not 100% about my attempts to identify "safe" and "not safe" methods

I did some research but I don't have easy access to jQuery at the moment to verify, so a second opinion would be appreciated

I don't know those parts either. I trusted you on knowing the jQuery stuff :D

Though the injection can be wonky

You have <a href="$injection">Link</a>

I found an online jquery executor to confirm. prop does appear to be perfectly safe.

And by just injecting a script and closing the tag, you get <a href=""><script>stuff</script>">Link</a>

2:22 PM

There's definitely more ways for it to be dangerous than safe

The dangling "> may be a problem to get the exploit working

perhaps try injecting <script>evilStuff()</script closingAttr="

That actually gave me some trouble with my test, but I'm confident enough now that my answer isn't full of crap...

Or better yet, use an image tag to inject!

"><img src=x onerror="inject()

Because then the dangling "> will be closed for you

Oh wait, I'm totally wrong

Oh wait, I'm not

Man XSS can be complicated sometimes...

But I do need to update my answer

Bah, I was going to share my test using your image payload, but I have to register to share. You'll have to take my word for it that it is safe :)

My realization was that it is safe as long as you append the data to an href that already exists. If you use the user data and set a brand new href then the user could inject javascript:alert(1) and execute a payload when you click the link. They still can't escape the href, but I briefly forgot that an href can be dangerous on its own

Yes. The javascript: scheme is dangerous

2:33 PM

Which is why I like this place: I learn so much everytime I run through something like this (even more so when there is someone to talk through it with).

I'm glad I can be of help. It's always nice to help someone, which is honestly why I am here

although now I've run through my allotted "question answering" time for the day. I don't usually spend a lot of time answering questions during the work day, but sometimes I get sucked in :)

I also can't decide if downvoting the other answer was reasonable or not. The advice is certainly sound: always sanitize user input. However, I objected to the assertion that the code was vulnerable. That depends entirely on what actually happens behind the scenes, and you can't know for sure if there is a vulnerability without further information...

Yeah, I understand you. Man, I should work on this document too, but...BOOOOORING

@ConorMancone That is correct. Just saying "I insert this" doesn't imply injection

3:05 PM

I think that "Password in Macro" question is going to hit the HNQ hardcore. It's obviously there already, but I suspect it will turn into one of those that hangs out for a week and ends up with 150+ upvotes

3:17 PM

Client needs it XML.

Do you know if it's possible via script to:

1. Create file.xml
2. Add 2 lines
3. Timer for 31 minutes
4. Add one last line (bottom/last line)
5. Wait until file gets opened/fetched/interacted with
6. Clear file
7. Loop back to 1

(Before I learn how to script it, any leads?)

You can script anything. Why not just write a script that reads the CSV, converts it to XML, and then sends it?

3:54 PM

Suggestion on how to separate/delimiter?

like

val0,val1,val2,val3
a,1,2,3
b,2,1,3
c,3,2,1
etc...

How to logically change to:

<XML Type blablab>
<root>

<ID value="a">
<val1>1</val1>
<val2>2</val2>
<val3>3</val3>
</ID>

<ID value="b">
<val1>2</val1>
<val2>1</val2>
<val3>3</val3>
</ID>

etc...

</root>

I'm not quite sure what you are asking. You need to write a script that reads the CSV and then writes XML. I wouldn't actually write a CSV reader or an XML writer (both have a surprisingly large number of gotchas). I'd pick a language I'm comfortable with, grab a CSV reader, grab an XML writer, and write the script to put the pieces together

Are you looking for help on how to practically write such a script?

4:20 PM

I'm just trying to find a stable and reliable solution to my XML issue.

I have a software that outputs to a CSV programatically

I need to get these values and output it in an XML, simplest way possible, one script, no additional util.

Can python f(open) then save output into another file?

Can't I do something like:
import csv

$head = <XML type blabla> CLRF <root>
$foot = </root>

f(open) my.csv
$pyvalue0 = val0
$pyvalue1 = val1
$pyvalue2 = val2
$pyvalue3 = val3

f(write) my.xml:
head

for each line in my.csv (starting from line 2)
f(write) my.xml:

<value0 ID="$pyvalue0">
<value1>$pyvalue1</value1>
<value2>$pyvalue2</value2>
<value3>$pyvalue3</value3>
</ID>

then

f(write) my.xml:
foot

then

f(close)

5:18 PM

Yes and no.

As I mentioned, CSV and XML both have a number of gotchas, so having a library handle those things is probably a good call (and usually much easier than trying to do it yourself)

For instance, it is taken as a given that a CSV has one line per row, but this is not actually accurate

CSV can use double quotes to enclose strings that span multiple lines. Then, to include a double quote, the CSV file will write out a double-quote twice.

If you have either of those going on in your data, then the easiest option will be to just find a CSV parser

On the writing side, your output needs to be escaped before it can be written out as XML. After all, what happens if there is a < or > in your data? Just one will break the entire file and it will no longer be parseable as XML. There are also other characters that can break an XML file and require output encoding

So can you do that? Sure, based on simple assumptions about the CSV and the data which may break at anytime, causing the whole thing to stop

2 hours later…

7:46 PM

Gotcha.

But here's what I have in mind:

I can indeed export directly in xml but it lacks the root (main) tag/container. (Since it's a loopable flow for each processed document, I can't predict the amount of documents but I can predict when the other system will import so I will use that predictable element to make a 30m sync.

SO... the flow will, instead of being real-time, agglomerate the files before processing.
Send all the files to be processed at 29m it's pretty instant/quick, even for 100 documents, needs to be tested though so I can adjust the proper timing.

Details: The exportation will work perfectly since I can group the documents using the attribute function (Like so:

<ID value=" $myIDfieldvalue "> #using my required "space" separator. I call also add a last step in workflow process to add line </ID> which can be used to close all the opened ID tags since only the value will change.

so even if I send 5000 documents at once, the elements of the XML will be perfectly outputed. Only issue left is "<XML Type> && <root> / </root>"

8:20 PM

@ConorMancone Catch my drift?

8:42 PM

Are you exporting as XML or are you changing the delimiters so it outputs something that looks like XML?

I mean, if you think it will work than go for it. It sounds like you have a plan, and your the only one who is in a place to find out if it will work or not. I would worry that the process you are trying to build is going to be very brittle and prone to breaking. Writing a script that reads CSV and exports XML on command sounds like it will be both simpler and more reliable. That's just my opinion though. Do whatever makes sense to you

I can't code properly and in a timely fashion.

It exports in the following manner for each document:

<ID value=" value0 ">
<tag1> value1 <tag1>
<tag2> value2 <tag2>
<tag3> value3 <tag3>
</ID>

I processed various output tests in xml validator, no issues.

Then go for it!

Yay thx

« first day (3276 days earlier) ← previous day next day → last day (1596 days later) »

Transcript for

Dec '195

The DMZ

A serious place where infosec is discussed PS we don't do hard...

404-errors moderate-anarchism pretending-to-work staring-into-the-abyss

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile